Wiktionary:Grease pit/2021/December

Can't add vote to active votes

Wiktionary:Votes/2021-12/User:Fytcha for admin needs to be in Wiktionary:Votes/Active but it doesn't work when I do it. Please help. Also can we make this process easier? I don't think I've ever been able to make a vote work without asking for help and I've been here like 15 years. I follow all the instructions carefully but no dice. Equinox ◑ 03:22, 2 December 2021 (UTC)[reply]

I agree. Something always goes wrong with this procedure, and the error message is always hopelessly unhelpful. Mihia (talk) 22:56, 27 December 2021 (UTC)[reply]

Edit doesn't appear in history

This 22 July 2016 edit [1] from an anon IP shows the text "1. Creatures in the pokemon game" which does not appear in the history of pocket monster, and there's no record of deletion or any logs other than creation. The anon has no contributions, not even deleted contributions, and no block or other logs. How is this possible? DAVilla 12:13, 3 December 2021 (UTC)[reply]

It was an edit attempt not published. AbuseFilter triggers a warning to the user trying to save such an edit. Then he can confirm to publish it anyway or not. --Vriullop (talk) 21:18, 3 December 2021 (UTC)[reply]

Ah OK, thank you. DAVilla 15:21, 5 December 2021 (UTC)[reply]

Contents List Pushing Down Conjugation Templates

If placed on the right via Gadgets under Preferences, the Table of Contents pushes conjugation templates like {{fo-conj-30}} down and away from the header. --Apisite (talk) 23:02, 5 December 2021 (UTC)[reply]

Many such tables could be narrowed without grievous harm to appearance to coexist on friendlier terms with RHS table of contents. DCDuring (talk) 04:02, 6 December 2021 (UTC)[reply]

Wanted: Mediawiki support for the language of a section

The way Mediawiki and Wiktionary work, every entry here is completely riddled with repetitions of the language code, for example "nn" in a Nynorsk entry: {{wikipedia|lang=nn}}... {{inh|nn|non|askr}}... {{IPA|nn|/ɑsk/}}... {{nn-noun-m1}}. Isn't it time that we ask Mediawiki developers for a way to declare a whole section (from one h2 heading to the next) to have the same default value for the language parameter? It seems such a change would save us so much work, so many potential errors. Instead of passing the language code as 1st parameter (or named parameter lang=) to each template call, the templates could just use a system parameter {{LANG}} which would somehow be set in the background for the entire section of a page (just like {{PAGENAME}} is set). --LA2 (talk) 17:42, 7 December 2021 (UTC)[reply]

I think we went through this at some point in the past if you want to search for old discussions. DTLHS (talk) 17:45, 7 December 2021 (UTC)[reply]

See phab:T122934. One long-standing blocking task (phab:T114072) has been marked as resolved, so maybe this is getting closer. – Jberkel 17:55, 7 December 2021 (UTC)[reply]

Not bad. But we also don't want to litter every page and section with some {{#sectionproperty: declare | lang=en}}. It should just work, as soon as I write ==English== or ==Nynorsk==. How hard can it be? --LA2 (talk) 18:10, 7 December 2021 (UTC)[reply]

One approach that has come up multiple times in the past is to have each language section be its own dedicated page -- essentially, its own container at a unique database address -- so all the data in that container would be for that language. This would make it trivial to watch only those languages one wants. (Case in point, for myself personally, I care about a#Japanese, but not about anything else on that page. Seeing edits to entries for languages I don't care about is just noise.) Depending on implementation, splitting languages out to their own pages might also help us deal with certain memory issues. We could still show all languages for a given graphemic representation via transclusion. But this has also been shot down every time it is brought up.

"It should just work", and "How hard can it be" -- ah, you appear to be new here. :) (Not literally "new" per your edit history, but perhaps "new" to these kinds of discussions.) Carry on, and good luck! ‑‑ Eiríkr Útlendi │^{Tala við mig} 18:57, 7 December 2021 (UTC)[reply]

If all content was moved to subpages, one per language section, and the main page (e.g. a, ask, good) just contained {{/en}}{{/af}}{{/it}}{{/ja}}{{/nn}}{{/sv}} the whole would look just the same to the reader. As soon as you click "edit" next to a section heading (which would have to be present in each subpage), you would just edit that subpage. This would be possible under the current Mediawiki software, but templates would have to pick out the components of the PAGENAME. And someone would have to update the list of inclusions in the mainpage, when new sections are added or removed. It would be a big change to all editors, and you could technically still put ==Danish== in the /pl subpage.

In addition to my edit history, I also used to maintain my own wiki software (2001–2003), so I'm not "new" in that field either. It should be possible to make a {{SECTIONNAME}} available to templates, analogous to PAGENAME. Some templates want the name ("English"), some want the code ("en"). Translating between them should be easy. --LA2 (talk) 20:04, 7 December 2021 (UTC)[reply]

That's how I understood it would work (magic word or similar). Maybe we should poke them again on phabricator, now that the other ticket is resolved. – Jberkel 20:33, 7 December 2021 (UTC)[reply]

@LA2, I have no argument about your technical ideas or expertise. I merely meant to humorously bring up my own frustration about how such proposals have so often gotten mired in community hemming and hawing or outright opposition. Your expressions of "It should just work", and "How hard can it be" suggest that you might not have experienced these disappointments. The human element here often proves more difficult than the technical. I admire your hopefulness, and would also like to see us (the EN Wikt editor community) do something more effective with our platform. ‑‑ Eiríkr Útlendi │^{Tala við mig} 18:46, 8 December 2021 (UTC)[reply]

Akkadian and Hittite fonts

It would be nice if we could display the appropriate fonts for Akkadian and Hittite. They currently do not represent very faithfully the language as it was written. There are some great fonts we can use here. Does anybody know how to go about this? ObnoxiousCoder (talk) 23:34, 7 December 2021 (UTC)[reply]

I notice that if you click the gear icon on the left sidebar, a menu pops up providing an option to apply certain webfonts. (One is a clone of Comic Sans, the other a font designed to make reading easier for those with dyslexia.) I am not sure if this list could also be expanded to include fonts for scripts like Cuneiform that aren't widely supported.

Alternatively, administrators could edit the site's JavaScript and CSS to load the font directly, accomplishing the same thing as the pop-up menu, although given the file size of webfonts, it seems prudent to only run such code on pages that need it. Presumably the code could detect the presence of a particular language section on a page, for example.

If those options are all ruled infeasible, the only solution remaining may be to ask users to install such a font locally. 70.175.192.217 19:51, 10 December 2021 (UTC)[reply]

Dutch groter als/groter dan

Hi,

I couldn’t help but notice the third entry for the preposition ‘als’. It says ‘als’ may be used as ‘than’ in nonstandard sentences. Using it like that is widely believed to be incorrect, should the entry be marked as such? The Dutch wiktionary doesn’t include ‘than’ at all.

Blue red links

When I use Cyrillic vowels with acute accents in Macedonian headword-line templates in order to indicate the stress of the forms or related terms that I am supplying, the latter appear as blue if a target page exists, even though that page itself will not have the acute accent in its title; in other words, the acute accents are appropriately stripped in the linking process. However, they still cause the page on which they appear to be assigned to "Macedonian POS with red links in their headword lines". For example, диригент currently has диригентка as a feminine equivalent in the headword line, and the link is blue because a page for диригентка exists, but if I respell it as "дириге́нтка", the link will remain blue and assign диригент to "Macedonian nouns with red links in their headword lines" even so. Furthermore, if I respell it as [[диригентка|дириге́нтка]] OR [[дириге́нтка|диригентка]], диригент will not be assigned to the aforementioned category. It would perhaps be desirable to change the code which populates red link categories so that it disregards links which actually appear as blue on the page. The whole point of creating "Macedonian POS with red links in their headword lines" was to help me and my fellow contributors to create pages which do not yet exist. With the false positives due to the use of acute accents, the utility of the red link categories is undermined. Martin123xyz (talk) 21:30, 10 December 2021 (UTC)[reply]

@Martin123xyz Should be fixed. Benwing2 (talk) 00:42, 13 December 2021 (UTC)[reply]

Thank you. It works well now. Martin123xyz (talk) 07:23, 13 December 2021 (UTC)[reply]

Pre-filling language names for RFVN and RFDN

One of the challenges faced at WT:RFVN and WT:RFDN is that it is not always easy to identify the language of each challenged term. In order to normalise a practice of writing the language name at the beginning of the listing, I'd like to suggest a preload system where the language name is automatically filled in when the user lists the RFV/RFD, similar to how {{rfv-sense}} pre-fills the text "Rfv-sense".

From a technical standpoint this could be accomplished by creating Template:rfv/preload with the content $1. and changing the pre-filled section creation link in {{rfv}} to something like

[{{fullurle:Wiktionary:Requests for verification/{{#switch:{{#if:{{{lang|}}}|{{{lang|}}}|{{{1|}}}}}|en=English|zh|ja|ko=CJK|#default=Non-English}}|action=edit&section=new{{#switch:{{#if:{{{lang|}}}|{{{lang|}}}|{{{1|}}}}}|en|zh|ja|ko=|#default=&preload=Template:rfv/preload&preloadparams%5B%5D={{langname|{{{lang|{{{1|}}}}}}}}}}&preloadtitle=%5B%5B{{urlencode:{{FULLPAGENAME}}}}%23rfv-notice-{{#if:{{{lang|}}}|{{{lang|}}}|{{{1|<noinclude>und</noinclude>}}}}}-{{{topic|}}}%7c{{urlencode:{{FULLPAGENAME}}}}%5D%5D}} +]

Then, when you click the "+" link, the text area will be pre-filled with the relevant language name, for instance: Middle French. A similar thing could be done for {{rfv-sense}}, {{rfd}} etc. This, that and the other (talk) 04:34, 16 December 2021 (UTC)[reply]

I like this idea, it's much better than hoping that every editor remembers to manually add something that can be automatically generated. JeffDoozan (talk) 01:08, 17 December 2021 (UTC)[reply]

If someone would make me a template editor I would do it myself... I have the template editor right on Wikipedia if it's any help... This, that and the other (talk) 10:42, 20 December 2021 (UTC)[reply]

{{look}}

I'd be very grateful to any template editor or administrator who would be willing to assist, whether by implementing the proposal, or by granting the rights so I can implement and test it myself. This, that and the other (talk) 11:08, 24 January 2022 (UTC)[reply]

@This, that and the other: I can temporarily lower the protection level of {{rfv}} to autopatrollers if you want. Just ping me when you're done, okay? — Fytcha〈 T | L | C 〉 13:22, 24 January 2022 (UTC)[reply]

@Fytcha: Thanks, that would be great. I want to do it for rfv-sense, rfd etc too, but let's attack one at a time. This, that and the other (talk) 13:24, 24 January 2022 (UTC)[reply]

@This, that and the other: Lowered it for {{rfv}} and {{rfv-sense}} for now. Ping me when you need more and/or are done with these two. :) — Fytcha〈 T | L | C 〉 13:28, 24 January 2022 (UTC)[reply]

@Fytcha Done those. Now {{rfd}} and {{rfd-sense}}? They're the only other ones I can think of. This, that and the other (talk) 13:44, 24 January 2022 (UTC)[reply]

@This, that and the other: Unprotected. — Fytcha〈 T | L | C 〉 13:48, 24 January 2022 (UTC)[reply]

@Fytcha The only one left now is {{rfc}}, but I can handle that myself. Thanks very much for your assistance! Maybe one day I'll get to be a big boy and edit templates all by myself. This, that and the other (talk) 14:01, 24 January 2022 (UTC)[reply]

@This, that and the other: You're welcome! — Fytcha〈 T | L | C 〉 14:03, 24 January 2022 (UTC)[reply]

@Fytcha I'm very sorry, but I've found a bug in my code: I failed to check what would happen on multi-word language names (see -lending as an example). Could you please apply the change here to the other four templates (namely, wrapping the call to {{langname}} in a {{urlencode:...}} magic word? This, that and the other (talk) 02:38, 25 January 2022 (UTC)[reply]

@This, that and the other: Done, please verify my four changes. — Fytcha〈 T | L | C 〉 02:46, 25 January 2022 (UTC)[reply]

@Fytcha looks great, thanks! This, that and the other (talk) 02:55, 25 January 2022 (UTC)[reply]

@This, that and the other There are now several non-mainspace pages in CAT:E due to the impossibility of infering language codes for rfdo. This needs to be addressed. It seems silly to require adding "und" as a language code in such cases. Chuck Entz (talk) 14:58, 24 January 2022 (UTC)[reply]

@Chuck Entz That's because people are putting in information that is not a language code into the first parameter. As far as I can see, this would never have worked even before my changes, so I have just edited these invocations in order to fix them. Apologies for the mess! This, that and the other (talk) 00:30, 25 January 2022 (UTC)[reply]

Referencing a glossary in Wikisource

I'm currently trying to create an entry for an Old English word whose gloss can be found in a glossary on Wikisource. Would someone be able to help me make a reference template for this? Here is the glossary: Bright's Anglo-Saxon Reader/Glossary

Make Template:lb stop categorizing in the Citations namespace.

If Template:lb is in the Citations namespace, it will currently categorize the same way it would in the mainspace. For example, a label of "Scouting" in Citations would put a Citations page in Category:en:Scouting. Any way to solve this issue? And are there other templates that cause similar issues in the Citations namespace that now would be a good time to address as well? PseudoSkull (talk) 18:45, 22 December 2021 (UTC)[reply]

Fully Implementing Template:R:Century 1911

Currently, many of the parameters listed in the documentation for Template:R:Century 1911 have not been implemented, see the "Examples" section of the documentation for straightforward evidence. Would anyone be willing to implement them, maybe in a way similar to that of Template:R:Century 1914? Thank you and take care. —The Editor's Apprentice (talk) 02:13, 21 December 2021 (UTC)[reply]

Done. I removed accessdate as what is actually being referenced is Century 1911 (which will never change), not the website itself. This, that and the other (talk) 11:26, 21 December 2021 (UTC)[reply]

Fair enough! Thanks for the quick work and response. —The Editor's Apprentice (talk) 21:00, 21 December 2021 (UTC)[reply]

While we are at it, could we add a parameter to indicate whether the relevant entry is in the main Dictionary, the Supplement, or both? At present the user has to click through to one or the other as the url is not present. At some point, could the template be enhanced to automagically go to the actual entry page instead of requiring the user to click through or the url to be added? DCDuring (talk) 22:39, 21 December 2021 (UTC)[reply]

Wikidata integration?

Hi. I have been active on Wikidata for a while and recently the connection from Wikidata to WT went live on 2 Wiktionaries.

This is an important step in separating view and model IMO and makes wiktionaries potentially a lot more valuable when they present data that is stored in Wikidata instead of mixing data and presentation as we do now.

ML and NLP seems to me to be on the rise and good dictionaries for stemming etc. are missing for many languages. WT and WD can help build a better world with good multilingual support easily available if we work together. Do we have consnsus for starting this transition?--So9q (talk) 09:44, 22 December 2021 (UTC)[reply]

I think most people aren't aware what's going on, can you give a short summary? As usual, there has been very little information from the Wikidata project itself, and very few editors are active in both. Will it be possible to edit data on Wiktionary, or do you always have to go through Wikidata? Are there statistics/overviews on what kind of data is currently available, ordered by language? Where does it make sense to use the data? – Jberkel 00:08, 23 December 2021 (UTC)[reply]

Certainly there is no such consensus. In my view it is a great strength to be machine illegible. DTLHS (talk) 01:41, 23 December 2021 (UTC)[reply]

I think on a basic level that's the fundamental difference between the projects: Wiktionary is geared towards human readers, like traditional users of a paper dictionary, whereas Wikidata optimizes for data reuse, like above-mentioned ML models/algorithms. In the future probably fewer people will care to know what part of speech a word is; AI-based auto-correction tools do the job for you. – Jberkel 08:36, 23 December 2021 (UTC)[reply]

Exactly. The strength is resistance to colonization by machine learning zealots. DTLHS (talk) 17:45, 23 December 2021 (UTC)[reply]

I would be very interested in this. Separating the model from the view would have benefits both for ML and Wiktionary itself, but it would be an enormous undertaking, as the current dataset is a Mandlebrot of edge cases. As the previous responses have mentioned, it's build by humans for humans and its greatest strength is the ease with which a new user can add and edit not only the data but also the structure and I doubt there would be any consensus for changes that would dramatically alter that. Can you provide some more information about which other projects were migrated, how it was done, and how their communities have responded? JeffDoozan (talk) 12:32, 23 December 2021 (UTC)[reply]

If Wikidata can use what we have, more or less as is, why do we even need to cooperate? If there are relatively minor changes that would make it easier for Wikidata to do so, couldn't they be addressed on a case-by-case basis? Some higher degree of uniformity in presentation might be acceptable. I am quite sure that there is no consensus here to do any violence to any human language to fit it into any particular model that Wikidata might have.

So far, in the area of taxonomic names, one of the most highly structured sublanguages, I have not been impressed by the quality of some of what Wikidata had to offer. Images associated with species were sometimes wrong and images associated with genera were not of type species, even though type species pictures were available in Commons. For taxa I have tried to use drawings where possible instead of photographs, but Wikidata didn't seem to help with that. The one area for which Wikidata might help is the collection and maintenance of the various identifiers used by different taxonomic databases for taxonomic names. DCDuring (talk) 16:23, 23 December 2021 (UTC)[reply]

What kind of quality control does Wikidata have when it comes to foreign language translations of terms? I personally have little trust in their correctness, see for instance the German protologism here. I would be strongly opposed to bringing the foreign language data from Wikidata here to Wiktionary. Fytcha (talk) 17:02, 23 December 2021 (UTC)[reply]

What you linked to is the Wikidata representation of Wikipedia, the actual lexical data is stored in a different namespace (Lexeme:). For example, for Alkohol there is wikidata:Lexeme:L1836. That entry has gender information, a Duden identifier and inflected forms with pronunciation data. I'm not sure if there is a way to specify translations in WD, but there is a link to the "concept" of alcohol wikidata:Q47146337 (“active ingredient in alcoholic beverages”) which could be used to find equivalents in other languages. The primary sense ("ethanol") is not listed in WD for that lexeme. – Jberkel 17:31, 23 December 2021 (UTC)[reply]

A small thing with the rfap template

It would be nice if instead of "if you have a microphone", it also read "you are a native speaker with a microphone". We don't want to encourage people to record for languages they don't really speak. Vininn126 (talk) 13:59, 22 December 2021 (UTC)[reply]

@Vininn126: I've gone ahead and implemented the change. Good call. Ultimateria (talk) 23:06, 22 December 2021 (UTC)[reply]

Question about TOCs

It appears all entries that contain definitions for multiple languages have TOCs. What I'm confused by is the one-language words. Some have TOCs, some don't. To use some examples from Special:Random, demonología in Spanish does not have one, but boaro in Italian does. 70.172.194.25 02:53, 25 December 2021 (UTC)[reply]

I would guess that it has something to do with the number of headers, since those are the only things that show up in TOCs. Of your two examples, demonologia has only the one l2 header with two l3 headers, while boaro has one l2 header with three l3 headers and an l4 header. I added an extra l3 header to demonologia in preview, and the system displayed a TOC as soon as I clicked preview again. Likewise, I commented out everything between the "Italian" and "Noun" headers in preview, and the TOC disappeared- but it came back when I un-commented the "Pronunciation" header and clicked preview again. I don't know if it matters how many are which level, but you can test it for yourself by trying all kinds of combinations in preview, as long as you don't click "Publish changes" to save them. Chuck Entz (talk) 05:36, 25 December 2021 (UTC)[reply]

See [2]. Creating a ToC on very short pages would be a counterproductive waste of space. Equinox ◑ 05:39, 25 December 2021 (UTC)[reply]

Two new Russian categories - one new and one to be created yet

I have just created a new Russian category: Category:Russian abstract nouns, which should be able to cover a large number of nouns formed from adjectives (-ость adjectives) (as a shortcut, rather than creating a full definition, which is just a repetion of adjective senses).

The category seemed a bit problematic, so I used:

{{catfix|ru}}

[[Category:Russian nouns]]

Not sure if this is ideal.

Also, I used verbal noun templates on some new words like ослепле́ние (osleplénije): {{infl of|ru|ослепля́ть||vnoun}}. The term wasn't added but I'd like it to be added to Category:Russian verbal nouns automatically.

(Notifying Benwing2, Cinemantique, Useigor, Guldrelokk, Fay Freak, Tetromino, PUC, Brutal Russian): Are you happy for these new categories to be added? Please fix if anything needs fixing. --Anatoli T. ^{(обсудить}/^вклад) 04:47, 27 December 2021 (UTC)[reply]

@Atitarev The categories seem OK with me and I can fix the category code to define them properly. However, I'd prefer it if you can gloss the terms whenever possible, e.g.

# {{abstract noun of|ru|дото́шный}}: [[meticulousness]]

or

# {{verbal noun of|ru|ослепи́ть|t=to blind, to dazzle}}

If there are several senses, I think it's fine to gloss the most common ones and write etc. to stand for the rest. Also, I'm curious why you are using {{infl of|ru|ослепля́ть||vnoun}} instead of just {{verbal noun of|ru|ослепля́ть}} (which already categorizes properly). Finally, is it correct to gloss a noun like ослепле́ние (osleplénije) as the verbal noun of both ослепи́ть (oslepítʹ) and ослепля́ть (oslepljátʹ), since it's morphologically derived from the former rather than the latter? If so I should probably fix the form-of templates so you can write something like {{verbal noun of|ru|ослепи́ть|t=to blind, to dazzle|term2=ослепля́ть}} or even {{verbal noun of|ru|ослепи́ть,ослепля́ть|t=to blind, to dazzle}} and have it work correctly. Benwing2 (talk) 05:08, 27 December 2021 (UTC)[reply]

@Benwing2: I agree with your points and I started changing. I used {{infl of|ru|ослепля́ть||vnoun}} since it's the way it was used so in Macedonian and other entries (probably not categorising by this template call) and I wondered why Russian lacks this category.

Abstract nouns in -ость (-ostʹ) and verbal nouns in -ние (-nije) are mostly predictable in how they are formed from adjectives and verbs and have predictable declension and stress patterns, so it would be ideal if these could somehow be added to the accelerated entry creation or generated by bots but I have no idea how difficult it is. :) --Anatoli T. ^{(обсудить}/^вклад) 05:27, 27 December 2021 (UTC)[reply]

@Atitarev It is pretty easy to add accelerator support for abstract nouns and verbal nouns (and to add a parameter to {{ru-verb}} to support specifying verbal nouns in the headword). It's also not that difficult to support generating them programmatically if you specify |absn=+ or |vn=+; for the latter case I can reuse the code that generates past passive participles since as far as I know the verbal noun can be derived fairly directly from the participle. I will probably add the accelerator support first and then the + support. Once this is done I will look into modifying existing entries by bot to incorporate {{abstract noun of}}/{{verbal noun of}}. Note that I did this already for {{feminine equivalent of}}. (In that case I did it semi-automatically and manually cleaned up the entries in the process, but there are too many nouns in -ость and -ение/-ание/-яние/-тие to do it this way: about 900 in -ость, about 950 in -ение, about 600 in -ание, about 100 in -тие and maybe 50 in -яние.) Benwing2 (talk) 07:04, 27 December 2021 (UTC)[reply]

Can anyone explain what/where this is, and how I edit its content? Mihia (talk) 17:27, 27 December 2021 (UTC)[reply]

It's a template: Template:U:en:who and whom. "U" is a pseudo-namespace for usage notes, like "R" for references. This, that and the other (talk) 06:11, 28 December 2021 (UTC)[reply]

Thanks, duh, I'm sure I searched for "template:u:..." and nothing came up, but now it does. Maybe I'm going mad. Mihia (talk) 09:42, 28 December 2021 (UTC)[reply]

Dodgy WT:ACCEL

I auto-made sobrevaluarlas, and it looks dodgy. Compare comerlas, which is in the format I was expecting to see. I can't fix them! Br00pVain (talk) 21:11, 27 December 2021 (UTC)[reply]

Making Template:quote-av handle non-fiction works better

Currently, Template:quote-av prefaces quote with "spoken by <role> (<actor>):" if values for the role and actor parameters are given. If the role parameter is not given a value, no preface occurs. This function, formatting, and naming of parameters makes quoting non-fiction audio-visual works, as well as fiction works were someone plays themself, awkward. Is someone willing to modify the template, as well as Template:cite-av, to remedy the situation? One solution for the formatting would be to switch the parameters so that the format is "spoken by <actor> (<role>):" and have it display if there is no role parameter as "spoken by <actor>:". If there is a role, but no actor given it could be "spoken by <role> (role):" Maybe a good alternative name for the parameter actor would be speaker. (As a side note, if a signed langue is being quoted, I don't know how much it makes sense to say the quote is "spoken" by someone. Maybe a parameter called signed could be created as a boolean if set to 1 or on it replaces the word "spoken" with "signed".) Thanks and take care. —The Editor's Apprentice (talk) 00:02, 29 December 2021 (UTC)[reply]

Fixing plurals in ms-noun

When this template {{ms-noun}} is used in Jawi (Arabic script) lemmas, the plurals are displayed as two like found in مکتب. Actually, plurals in Jawi is only مکتب۲ and not مکتب-مکتب. The latter is only used for Rumi (Latin script). Please remove the latter for Jawi lemmas. --Tofeiku (talk) 03:15, 29 December 2021 (UTC)[reply]

Community Wishlist Survey 2022 is coming. Help us!

The Community Wishlist Survey 2022 starts in less than two weeks (Monday 10 January 2022, 18:00 UTC). We, the team organizing the Survey, need your help.

Translate important messages

Promote the Survey

Among anyone and everyone you know who has an account on wiki.

Promote the Survey on social media, via instant messaging apps, in other groups and chats, in your WikiProject, Wikimedia affiliate - wherever contributors with registered accounts may be.

Only you can make the difference

How many people will hear and read about the Survey in their language? How many will decide to participate? Will there be enough of you to vote for a change you would like to see? It all depends on you, volunteers.

Why are we asking?

We have improved the documentation. It's friendlier and easier to use. This will mean little if it's only in English.
Thousands of volunteers haven't participated in the Survey yet. We'd like to improve that, too. Three years ago, 1387 people participated. Last year, there were 1773 of them. We hope that in the upcoming edition, there will be even more. You are better than us in contacting Wikimedians outside of wikis. We have prepared some images to share. More to come.

What is the Community Wishlist Survey?

It's an annual survey that allows contributors to the Wikimedia projects to propose and vote for tools and platform improvements. Long years of experience in editing or technical skills are not required.

Thanks, and be safe and successful in 2022! SGrabarczuk (WMF) (talk) 03:15, 29 December 2021 (UTC)[reply]

Monthly Discussion Pages

You may not be aware of it, but monthly discussion pages wouldn't be on anyone's watchlist unless they were created in a certain way before being used. For the second year in a row, no one has done this. Last year, I went ahead and created all the pages at the last minute to avoid having new discussion stop showing on everyone's watchlist. This year, I created just the ones for January, but would like us to set up a process so it doesn't depend on one person.

Note that failing to do this won't prevent the creation of the new pages, but the new pages won't be on anyone's watchlist.

It's not all that complicated: it takes advantage of the fact that moving a page causes every watchlist that includes the old location to have the new location added with the same settings as the old one, but without removing the old one. There are three steps required for each page created:

Move the old page to the new one, leaving a redirect
For instance, you would move Wiktionary:Grease pit/2021/December to Wiktionary:Grease pit/2022/January.

Wiktionary:Grease pit/2021/December is now a redirect to Wiktionary:Grease pit/2022/January
Move the new page back to its old location over the redirect, leaving a redirect behind
Wiktionary:Grease pit/2021/December is now the same as it was before you moved it away and moved it back.

Wiktionary:Grease pit/2022/January is now a redirect to Wiktionary:Grease pit/2021/December.
Replace the redirect in the new location with {{discussion month}}

Once the January page is finished, you can then use this page to create the next one and the next one, etc. As long as the chain of moves is unbroken, they will all be in the same watchlists.

The series in question:

Some considerations:

It's best to have as little time as possible between the first and second steps when an active discussion page is moved, to avoid edit conflicts
I'm not sure if it's necessary, but: to be safe, I would recommend starting with the most recent active page in a series, so the status in everyone's watchlists is as up to date as possible.
This needs to be done by an admin: the relevant pages are protected against moving by anyone else.

This whole process was started by @Rua who has said she will share her script for doing this. Chuck Entz (talk) 19:08, 31 December 2021 (UTC)[reply]

I did share the script, but I forgot where. In some BP or GP page somewhere. —Rua (mew) 20:18, 31 December 2021 (UTC)[reply]