Wiktionary:Beer parlour/2022/May

{{lb}} now seems to link terms to principal namespace entries and, in their absence, WP. This seems needlessly distracting and sometimes wrong. We tend to use each word in a label with a specific definition. Our principal namespace entries often have multiple definitions, so readers have to waste time finding the relevant definition. The problem is worse with labels like MLE and AAVE. In the case of MLE, the user who naively clicks on MLE finds a long WP article. That is not usually what a dictionary user expects or deserves. I think there is some manifestation of leading the user to betterment (in someone's opinion anyway) by 'nudging' them to the article. It seems like an abuse of power to me. DCDuring (talk) 16:42, 2 May 2022 (UTC)[reply]

Shouldn't we eliminate ALL links directly to WP from labels and replace them with glossary entries, which may contain WP links to lengthy articles with some indication that one is in for a non-dictionary experience? DCDuring (talk) 16:56, 2 May 2022 (UTC)[reply]

I could see a glossary space being useful. We would probably expand the glossary we already have. Vininn126 (talk) 17:22, 2 May 2022 (UTC)[reply]

That's what I had in mind. I suppose it would be OK to link to our own mainspace entries if the entry contained only one or two definitions or if we linked to a specific sense. DCDuring (talk) 19:08, 2 May 2022 (UTC)[reply]

A {{label}} parameter will only produce a link if it is included in a list of such parameters. For example, {{lb|en|Australian Aboriginal mythology}} displays as “(Australian Aboriginal mythology)” with a link to the article Australian Aboriginal religion and mythology on Wikipedia. This is specified on line 244 of Module:labels/data/topical. The rule for “MLE” is found in line 131 of Module:labels/data/lang/en. The label “derogatory” leads to the Wiktionary entry derogatory, see line 936 of Module:labels/data, while on line 945 we see that “dialect” links to Appendix:Glossary § dialectal. Volunteers for improving these links are free to do so.  --Lambiam 15:03, 3 May 2022 (UTC)[reply]

@DCDuring Have at, as the suggester. Vininn126 (talk) 22:44, 4 May 2022 (UTC)[reply]

More participants in this discussion would be nice. I will work on what I think are the biggest problems and make sure that there are Glossary entries (with links to WP where relevant). I hope that {{sense-id}} can work or at least provide a model for a more specific template. DCDuring (talk) 23:53, 4 May 2022 (UTC)[reply]

Read this in another language • Subscription list for this multilingual newsletter

The New topic tool helps editors create new ==Sections== on discussion pages. New editors are more successful with this new tool. You can read the report. Soon, the Editing team will offer this to all editors at the 20 Wikipedias that participated in the test. You will be able to turn it off at Special:Preferences#mw-prefsection-editing-discussion.

Whatamidoing (WMF) 18:55, 2 May 2022 (UTC)[reply]

Discussion tools make the discussion pages 1000x easier to use in my opinion. I personally wish they were more "standard", I wonder how other people might feel about them. Vininn126 (talk) 14:32, 3 May 2022 (UTC)[reply]

I totally agree; the "reply" tool just magically came on for me one day, and it is so good. Everyone should give it a try. (Only issue is, it doesn't work properly on the root WT:BP, WT:GP etc pages, because of the tricks involved in transcluding the monthly subpage, due to phab:T259824.) This, that and the other (talk) 10:16, 4 May 2022 (UTC)[reply]

Currently, Mariupol Greek entries use the Greek script for their primary forms (for instance, νιρό), with the equivalent Cyrillic-script entries (in this case, ныро́) being designated as alternative forms. This is exactly the opposite of how Mariupol Greek is written in real life - given that Mariupol Greek has been written more-or-less-exclusively in the Cyrillic script since 1969, shouldn't the Cyrillic-script entries be the primaries and the Greek-script ones the altforms, rather than the other way around (except possibly for Mariupol Greek lemmas attested exclusively prior to the promulgation of the Cyrillic orthography, for which arguments could be made both ways)? Whoop whoop pull up ^{Bitching Betty ⚧️ Averted crashes} 14:21, 3 May 2022 (UTC)[reply]

Agreed. Thadh (talk) 14:34, 3 May 2022 (UTC)[reply]

I've gone ahead and expanded the Cyrillic entry, but the original revision can always be restored and viewed. I'll wait for this discussion to run its course before implementing the set-Greek-as-alternative-form part. Thadh (talk) 16:38, 3 May 2022 (UTC)[reply]

Where is it written in real life? Are books and newspapers being published? Can you give examples? Vahag (talk) 16:15, 3 May 2022 (UTC)[reply]

See [1] for a very detailed history of Mariupol Greek literature and activism, but I'll try to come up with links to actual literature online. Thadh (talk) 16:36, 3 May 2022 (UTC)[reply]

Ah there you go: [2] (Rumeika starts at p. 115 I think). Thadh (talk) 17:13, 3 May 2022 (UTC)[reply]

Ok. Then we need a normalization scheme like Wiktionary:Udi transliteration, at least from Greek script to Cyrillic script. Vahag (talk) 19:52, 3 May 2022 (UTC)[reply]

Done: Wiktionary:Mariupol Greek transliteration. Thadh (talk) 21:13, 3 May 2022 (UTC)[reply]

Thanks. That's not the Greek system used in {{R:grk-mar:ST}}, but I think I can normalize their scholarly system into the Cyrillic chat alphabet based on the IPA. Vahag (talk) 14:52, 4 May 2022 (UTC)[reply]

Does French use ' (U+0027 APOSTROPHE) or ’ (U+2019 RIGHT SINGLE QUOTATION MARK)? The former one seems not recognized by the conjugation template, although quite a few pages of reflexive verbs use it. {{fr-conj-auto|s'habituer}} {{fr-conj-auto|s’habituer}} -- Huhu9001 (talk) 12:54, 4 May 2022 (UTC)[reply]

French typographers used apostrophes before anyone invented any digital character encoding system. In typeset books, both French and English, the apostrophe looks like a raised comma, best represented in Unicode by U+2019, which is sometimes referred to as the punctuation apostrophe. In typewritten text, it looks more like the U+0027 character. This character was inherited from ASCII, whose character set was largely derived from that of typewriters. The French Wikipedia uses U+2019, while the English Wikipedia uses U+0027, also in French titles.  --Lambiam 19:10, 4 May 2022 (UTC)[reply]

@Huhu9001 Upon further investigation, along with what Lambiam said, French Wiktionary also uses U+2019, along with l'Académie Française. L'Office quebeçoise de la langue française also prescribes U+2019, but does not go as far as to say that U+0027 is wrong and acknowledges that it's also been used nowadays. AG202 (talk) 19:27, 4 May 2022 (UTC)[reply]

I modified the template so it accepts both apostrophes now. -- Huhu9001 (talk) 04:35, 5 May 2022 (UTC)[reply]

On Ethnologue, it says the Tawellemmet Tamajeq language code is ttq. But when I try to put the code in on this site, it doesn't work. Can you probably fix this somehow?--ImprovetheArabicUnicode (talk) 18:59, 4 May 2022 (UTC)[reply]

We have the code tmh for Tuareg, but currently no further subdivision. Instead, for example iyăn is labelled as the Tamasheq form of əyyăn – while the latter does not further indicate of which specific Tuareg language this is a term. This is clearly unsatisfactory, but we do not have enough volunteers who are knowledgeable in this area.  --Lambiam 22:21, 4 May 2022 (UTC)[reply]

Pinging Malku H₂n̥rés.  --Lambiam 22:25, 4 May 2022 (UTC)[reply]

@ImprovetheArabicUnicode, Lambiam: we used to have true language codes for each Tuareg language, and we had almost no entry on them (IIRC, around 5 entries, all Tuareg languages combined but Tuareg (tmh)), whereas Tuareg itself (code tmh) has always had around 20 entries. So in August 2021, @Metaknowledge and I decided to merge all Tuareg languages into a single language code (tmh), and to turn the other ones into etym-only codes, namely:

• Ghat (tmh-ght)
• Tamahaq (thv)
• Tamasheq (taq)
• Tawellemmet (ttq) (so we still have this code, but now it's etym-only)
• Tayert (thz)

You can find this tree on "CAT:Tuareg language":

Accordingly, labels were put in the Tuareg entries to specify the Tuareg language(s) having this form of the lemma. Since, Tuareg has around 30 entries, each indicating which language it comes under; it's centralized thus more navigable and significant. Malku H₂n̥rés (talk) 20:17, 5 May 2022 (UTC)[reply]

I have heard on various occasions that we should have the ability to delemmatize alt spellings and forms. I've had it with some Polish editors, and recently @Thadh and @Sławobóg have both expressed interest in this. I believe either would be more able to explain why this would be useful for certain languages. I think if this is something we agreed on, it'd be an optional feature of the template, something like lemma=no in {{alternative spelling of}}. Vininn126 (talk) 23:12, 6 May 2022 (UTC)[reply]

So, a major problem is that if you have multiple competing standards (particularly in the same writing system) with one being more favoured and also lemmatised at on Wiktionary, it might benefit not to have the other(s) in the lemma category. I personally have this problem with Ingrian:

There is the standard language (kirjakeeli), which was designed in the 1930s and which we lemmatise our entries on (with slight typographical changes). However, since Ingrian remains officially unwritten, there is also a competing standard, designed by V. Chernyavskij, and which we give as soft redirects to the main entry. However, these entries still show up as lemmas, which makes the number of lemmas misleading and makes cleaning up wrongly lemmatised words pretty difficult.

Now, of course I could just create a specific template for Ingrian which categorises these forms as non-lemmas, but a similar case is true for a lot of languages where you can have numerous orthographical variants of one word, and only one page with an actual definition. So, seeing as this is a site-wide problem, we should probably come with a site-wide solution to this. Also, just to throw it in there, I don't really see the benefit of classifying typographical variants (say, long s'es, wynns) as lemmas. Thadh (talk) 23:30, 6 May 2022 (UTC)[reply]

To understand this, you need to know that the lemma/non-lemma category is set by the headword template, such as {{pl-noun}}, not by definition-line templates such as {{alternative spelling of}}. This already causes weirdness when there are homographic lemmas and non-lemmas, especially within the same POS, as at wound. Also remember that a non-lemma form of a noun goes in "Category:[language name] noun forms" rather than "Category:[language name] nouns".

Then there is the matter of the inflections of alternative forms, which can also be interpreted as alternative forms of the inflections of the main form.

Keeping all the headword-template permutations straight is confusing enough. Something like this would have to be done in the context of rethinking how we do lemma/non-lemma POS/Pos-form categories in general. It also adds to the ways that someone copying wikisyntax without understanding it can unknowingly mess things up. Having seen a decade of well-intentioned, but inexperienced editors get things horribly, horribly wrong, I'm a bit nervous about this kind of thing. Chuck Entz (talk) 00:38, 7 May 2022 (UTC)[reply]

Extended discussion seems like a minimum requirement for change. I get the feeling that something like this that purported to cover all languages would need a vote, if only to increase the chances that we would have extended discussion. I can think of all sorts of things that would need to be clarified: What about a given spelling that was apparently a lemma at one stage of a language's history, but became an inferior alternative form later? How would regional differences be handled, eg, US vs. UK, but probably others within English, eg. Indian English, AAVE, etc? It would be interesting to learn how MED handles the numerous spellings that existed in Middle English. DCDuring (talk) 21:32, 7 May 2022 (UTC)[reply]

Would it make sense, instead of categorizing some competing standards as not-lemmas (which is fraught, if users start un-wording a dialect's standard spellings, besides which it may be useful to have a category all the lemmas regardless of orthography go into), to add sub-categories like "Ingrian lemmas in Chernyavskij orthography", "Ingrian nouns in Chernyavskij orthography", etc vs "Ingrian lemmas in 1930s orthography" (or whatever the better name is!), similar to Category:Afrikaans terms in Arabic script, Category:Afrikaans nouns in Arabic script, etc? - -sche (discuss) 00:36, 9 May 2022 (UTC)[reply]

We could do that, but the two standards overlap, which would make such categorisation impractical in many cases.

What about subcategorising such forms but not letting them appear in the parent category? So, an entry like meez would be in the categories "CAT:Ingrian nouns in Chernyavskij orthography" and "CAT:Ingrian lemmas in Chernyavskij orthography" but not in "CAT:Ingrian nouns" or "CAT:Ingrian lemmas". Thadh (talk) 17:12, 13 May 2022 (UTC)[reply]

Potentially 2300 Euros and unlimited access to Sketch Engine. Y'all should know about this. Vininn126 (talk) 16:07, 7 May 2022 (UTC)[reply]

When I put the Jogi language code (jog), it appears to be not working. When I checked the ISO code for it ([3]) it said that jog it said it is the correct one. Can you probably add it on here?--ImprovetheArabicUnicode (talk) 18:51, 8 May 2022 (UTC)[reply]

@ImprovetheArabicUnicode: For a language code to "work", it has to be added to the modules. You can find all the language codes that "work" at Wiktionary:List of languages, and information on why we chose to recognize or not recognize specific language codes at Wiktionary:Language treatment and its talk page.

We don't automatically accept every language code that the ISO creates: in some cases their judgment is questionable, and they've been known to be simply wrong. More often, though, we just have our own reasons for treating languages differently than the ISO does. Deciding how to treat all the languages and dialects of the world over all of history is a monumental task which will probably never be finished, so there are cases like this one where we simply haven't decided what to do with a specific code. The general rule is: preview before you publish an edit, and don't publish it if you see a module error.

As for the matter at hand: the Jogi language may or may not be a dialect of Marwari- Wikipedia isn't very clear, and indeed has very little information. I don't know anything about it, so I won't comment. The only previous discussion I can find here is a list at Wiktionary talk:Language treatment of new language codes said to have "slipped through the cracks". Pinging @-sche, and (Notifying Mahagaja, Metaknowledge, AryamanA, Kutchkutch, Bhagadatta, Inqilābī, Msasag, Svartava): . Chuck Entz (talk) 23:57, 8 May 2022 (UTC)[reply]

Many of the codes on that list that "slipped between the cracks" were (AFAICT) omitted by mere oversight, or due to a naming conflict back when we bot-imported codes en masse. However, I know nothing about this one. I'm glad we have a number of Indian editors now, who hopefully have some idea — or at least better access to resources to check — whether it's a distinct language. - -sche (discuss) 00:28, 9 May 2022 (UTC)[reply]

@AryamanA, Bhagadatta, Chuck Entz, -sche: If User:ImprovetheArabicUnicode has data regarding the Jogi language, it could initially be added as under the Marwari language in

Category:Language-specific label data modules and/or

Module:etymology languages/data

and then moved to a separate language if needed. According to the previous discussions,

https://en.wiktionary.org/wiki/Module_talk:languages/data3/m#Mewari

https://en.wiktionary.org/wiki/Wiktionary:Language_treatment/Discussions#Merging_Marwari_.28mve.2C_rwr.2C_....29

Marwari is to be treated a macrolanguage and Category:Rajasthani language should be deprecated (which has not happened perhaps due to the existence of Category:Rajasthani lemmas). At

https://iso639-3.sil.org/sites/iso639-3/files/change_requests/2014/2014-016_jog.pdf

it says:

Lexical similarity percentages with related languages: Goaria 75-83%, Loarki 69-82%, Marwari (Southern) 70-78%

Although comprehension of other closely related languages such as Marwari and Dhatki might be satisfactory, sociolinguistic reasons would make acceptance of literature in another language unlikely, and despite relatively high lexical similarity percentages, the difference in personal pronouns immediately identifies these other languages as NOT Jogi.

Kutchkutch (talk) 00:51, 10 May 2022 (UTC)[reply]

@Kutchkutch: The situation in Rajasthan is quite complex, and I don't think any of the modern languages have a strong literary standard so adding them to Wiktionary will be tough. Will look more into the sociolinguistics of Jogi. @ImprovetheArabicUnicode: do you speak Jogi? —Aryaman^{A (मुझसे बात करें • योगदान)} 01:07, 10 May 2022 (UTC)[reply]

No, but I'm just adding languages and letters in the Arabic script on Wiktionary. ImprovetheArabicUnicode (talk) 01:16, 10 May 2022 (UTC)[reply]

Hello, Today we will migrate wiktionary.org portal to the new portals system (the one https://wikipedia.org has been using for years now). You can see the difference in phab:T304629#7911825. It is much more modern looking, has better search support and more aligned with Wikimedia design style guide. The meta page won't be needed anymore. Let us know if you encounter any issues. Ladsgroup (talk) 14:57, 9 May 2022 (UTC)[reply]

Go to bar and look at the category list at the bottom of the page. I think a lot of readers would be overwhelmed, as it is basically a huge wall of text. Categories that apply to different languages are placed adjacent to each other with no separation. In addition, you only see categories if you scroll all the way to the bottom of a page, so it is easy to overlook the list if you are interested in a language that is not located near the bottom of the page.

I'm not sure whether this situation can even be improved given technical limitations, but it is at least worth thinking about. Maybe having the categories for each language section listed right before the start of the next language section would be a reasonable solution. But even this is probably infeasible using the basic MediaWiki interface. 70.172.194.25 05:40, 10 May 2022 (UTC)[reply]

We could modify {{C}} so that it actually displays and links to the categories themselves. —Justin (koavf)❤T☮C☺M☯ 06:04, 10 May 2022 (UTC)[reply]

That is a possibility, but it would also require standardizing on only using {{C}} and not manual category links. Also, it would only show topic categories and not other things (although admittedly, these are among the most relevant categories for end-users). 70.172.194.25 07:49, 10 May 2022 (UTC)[reply]

Anyway, as a mockup of how an alternative design could look, here is a userscript that rearranges categories on a per-language basis: [4]. (Too lazy to post a modified version, but you might want to remove the line containing <br/> since on second thought it's too much whitespace between sections.) It can be placed into Special:MyPage/common.js or GreaseMonkey. I think it successfully reduces the information overload of the categories on pages like bar with many languages. It might break with HotCat enabled; didn't test it. 70.172.194.25 07:48, 10 May 2022 (UTC)[reply]

Yeah, as a general comment, we would benefit from thinking of ways to present information differently. There's lots of wasted whitespace to the right of headers (unless one fills some of it with images or {{wikipedia}}, but then some users have problems with that, as it takes up too much space on mobile, squeezing the definitions into a thin few-words-per-line or pushing them offscreen), and then there's walls of text at the bottom in the form of the categories, as you say. (How does "per-language basis" listing of categories interact with TabbedLanguages?) - -sche (discuss) 18:58, 11 May 2022 (UTC)[reply]

If you use tabbed languages, it will only display the categories relevant to the language you are looking at. I find that a lot more manageable. Theknightwho (talk) 21:30, 26 May 2022 (UTC)[reply]

You can find this message translated into additional languages on Meta-wiki.

More languages • Please help translate to your language

The Movement Strategy and Governance team is looking for community members to serve as election volunteers in the upcoming Board of Trustees election.

The idea of the Election Volunteer Program came up during the 2021 Wikimedia Board of Trustees Election. This program turned out to be successful. With the help of Election Volunteers, we were able to increase outreach and participation in the election by 1,753 voters in 2017. Overall turnout was 10.13%, 1.1 percentage points more, and 214 wikis were represented in the election.

There were a total of 74 wikis that did not participate in 2017 that produced voters in the 2021 election. Can you help increase the participation even more?

Election volunteers will help in the following areas:

• Translate short messages and announce the ongoing election process in community channels
• Optional: Monitor community channels for community comments and questions

Volunteers should:

• Maintain the friendly space policy during conversations and events
• Present the guidelines and voting information to the community in a neutral manner

Do you want to be an election volunteer and ensure your community is represented in the vote? Sign up here to receive updates. You can use the talk page for questions about translation.
--Mervat (WMF) (talk) 08:33, 10 May 2022 (UTC)[reply]

Continuing my ramblings about {{also}}, the more I think about it, the more I realize we should have a generic bot performing tasks that should be done across the site. Normalizing, alphabetizing L2's, and whatever we decide it should do. Perhaps it should add/remove nonlemmas as their links are added/removed from lemmas? (that might be controversial). Perhaps it should handle also (the code is still there). It should be able to do what Benwing's bot does and create non-empty categories and delete empty ones.

One problem that arises is who would run/control this bot? With some editors who perform these tasks with bots coming and going, the tasks they dealt with get ignored. I'm sure a lot of people would support this idea, but another issue is how to actually implement it. Should there be some faceless WMF bot? Vininn126 (talk) 22:19, 10 May 2022 (UTC)[reply]

It has been suggested a number of times that a Tools project for such a bot be created, that way it could be maintained by multiple users and it could leverage the databases available on Tools. - TheDaveRoss 12:39, 11 May 2022 (UTC)[reply]

What has been the stopping point for moving forward with that idea? Vininn126 (talk) 12:56, 11 May 2022 (UTC)[reply]

Is there a place where the functions of the various existing maintenance bots can be found and conveniently compared? For that matter, is there a place where one can report possible maintenance needs? DCDuring (talk) 16:05, 11 May 2022 (UTC)[reply]

It looks like we'd be using Tools, allowing various people to maintain it, and it would also be able to watch Recent Changes. Vininn126 (talk) 16:12, 11 May 2022 (UTC)[reply]

One maintenance task to consider: could we adapt Wikipedia's "signbot" to sign posts when people forget to do so (especially IPs on talk pages)? Perhaps it could be programmed to ignore edits that add RFV/RFD archives and any other likely sources of validly unsigned additions. Anyway, yes, as Dave said, running maintenance tasks on Tools — or at least requiring the code to be posted to Tools or to here(!) so new editors could run it if old ones leave — would be helpful. - -sche (discuss) 18:51, 11 May 2022 (UTC)[reply]

Sure. I also think anagrams could be on that list. Vininn126 (talk) 07:16, 12 May 2022 (UTC)[reply]

I don't like signbots: what if you edit your message? What if you edit someone else's message? I can see a lot of issues with signbots we don't want, and it's not like we really need them. Thadh (talk) 12:37, 12 May 2022 (UTC)[reply]

To be honest, discussion tools should probably be standard and they automatically sign for you. Vininn126 (talk) 12:39, 12 May 2022 (UTC)[reply]

1. "whatever we decide it should do" How do we decide? What is already being done?

2. What is the merit of a single all-purpose, or broad-range maintenance bot rather than single-purpose, narrow-range ones. DCDuring (talk) 12:45, 12 May 2022 (UTC)[reply]

@DCDuring You're missing the point. The big thing is not whether it's one bot or not but rather one not associated with a specific editor. Editors come and go, leaving these tasks unperformed as their bots leave, too. Having it be one bot would make maintenance easier.

Current potential list:

1. Alphabatize L2's
2. Make delete categories
3. Alphabetize/organize nyms
4. Organize l3's and lower
5. Make/Delete nonlemmas? Not so sure about this one.
6. Anagrams

Vininn126 (talk) 12:58, 12 May 2022 (UTC)[reply]

1. Sections of code within a single bot could still fall apart and have to be disabled when environment changes and the author/maintainer has left.
2. For narrow-scope bots, how about not giving permanent bot permission without acceptable documentation? Just allow one week - one month for testing. This would be easier to enforce on narrow-scope bots than on code sections within an all-purpose bot. We could start implementing this the next time bot permission is requested.

IOW, the underlying problem doesn't go away, it just takes a slightly different form. DCDuring (talk) 14:32, 12 May 2022 (UTC)[reply]

1) I don't see how that's any different from having multiple bots. The same problem exists there.

2) Who said anything about having unchecked, unacceptable documentation? All this code will likely come from existing bots.

I'm failing to see how these counterpoints actually prove anything. Vininn126 (talk) 14:45, 12 May 2022 (UTC)[reply]

Right, it may be the main problem is with missing documentation. I don't see that having a single bot is actually any better in any way than having multiple ones. And I don't see any practical means of protecting against missing or misleading documentation for portions of code within a single bot, whereas a single bot can be blocked if necessary. DCDuring (talk) 14:54, 12 May 2022 (UTC)[reply]

@DCDuring: I think the advantage here is that the bot would have code which was visible to everyone, and could be kept updated by more than one person. This means that if the environment changes the bot can easily be adapted, and if the owner moves on from the project we don't lose all of the work done to that point. Presumably the account under which the bot edited would be flagged as a bot, and the people who were maintaining the bot would endeavor to follow all of the current bot guidelines around making only changes which are non-controversial or which have been approved by the community. The goal isn't merely to have the bot code live in a repository on Toolforge, but to actually run on the Tools grid. - TheDaveRoss 16:47, 12 May 2022 (UTC)[reply]

Any such requirements could be imposed when bot permissions are requested. Eg, documentation, multiple sponsors, and a schedule or means of requesting the bot be run. All such requirements seem like they should be part of our normal practice with all bots. The problem would seem to apply to all bots worth allowing to run. DCDuring (talk) 17:11, 12 May 2022 (UTC)[reply]

It would be easier to have several bot sponsors if the bot is hosted on a server. Several users can log in to the server to run the bot; more eyes can look at the code and fix bugs or improve it; and the code for the bot would be available on the server if the bot operator has fallen off the map because of busyness, loss of interest, sickness, or death. No need for the bot operators to remember to push the bot code to GitHub or upload it to a website or email it to another Wiktionary editor so that someone else can take over running the bot. Wikimedia already spends time and money to maintain the Toolforge servers so we might as well use them. Quite a few people run bots for other Wikimedia projects on Toolforge (see this search).

In a non-bot area, User:Dixtosa made a Suffix Index website on Toolforge several years ago and recently gave me access so I could fix some bugs and improve it. Much easier and safer for him to let me do that on Toolforge than if it was running on his own computer or on a server that he'd paid for.

The other questions about how many distinct tasks a bot account should perform, whether to run a bot on a schedule or manually start it, how to disable a bot from performing a given task when it malfunctions, how much documentation to require for bot authorization, how to update a bot when the operating system or package ecosystem changes are independent of whether to use Toolforge and don't detract from the convenience of having a central location where several people can log in and edit bot code and run bots. — Eru·tuon 21:51, 12 May 2022 (UTC)[reply]

Does "hosting the bot on a server" allow for source control, bug reports, feature requests, code reviews, or anything like that? DTLHS (talk) 22:09, 12 May 2022 (UTC)[reply]

Ideally we'd have a git repository for the bot code and push to GitHub or GitLab so that people can easily find and read the code and post bug reports and feature requests, and the tool description should also link to a Wiktionary talk page so that people can post there if they don't have or don't want a GitHub or GitLab account. Several tools mention the GitHub URL in their description and others have a "source" field in the tool info that links to the GitHub page, like one of mine. — Eru·tuon 23:11, 12 May 2022 (UTC)[reply]

Sounds good. I hope we have enough interested talent to sustain such an effort. DCDuring (talk) 23:40, 12 May 2022 (UTC)[reply]

There are several different people that have written software tools that do most of what is described here so I think the problems are well understood. None of them have progressed into user friendly software that can be maintained and run collectively. DTLHS (talk) 01:09, 13 May 2022 (UTC)[reply]

If one bot does many things then there should be clear separation of concerns so that we can easily turn off one task and keep the others running (as rules change, etc.). Not just one big mash-up bot with all the tasks mixed up together, unless really important for performance. Equinox ◑ 17:22, 12 May 2022 (UTC)[reply]

Yeah, that makes sense. A section for function X, a section for function Y. Vininn126 (talk) 17:24, 12 May 2022 (UTC)[reply]

I reckon Wikipedia's invented that wheel already. probably somewhere in the murky depths of WP: —Fish bowl (talk) 05:19, 14 May 2022 (UTC)[reply]

Hello. I have noticed a massive increase on here of definitions of pop slang, politics, homosexuality, propaganda, and other sech things infesting this site. As far as I understood, this was supposed to be academic. And etymology dictionary. Not "urban dictionary"? What can be done to battle this non-academic cancer? Rosengarten Zu Worms (talk) 10:08, 13 May 2022 (UTC)[reply]

My god you're stupid...and I guess we can add homophobia to the list of your issues too huh..? If this is such cancer to you why don't you just leave? Acolyte of Ice (talk) 10:10, 13 May 2022 (UTC)[reply]

Lol Vininn126 (talk) 10:29, 13 May 2022 (UTC)[reply]

As of now, we only support IPA and enPR in most languages' pronunciation sections as far as I know. My question is: why? What about other phonetic alphabets: UPA, SAMPA, AA, just to name a few? Is it desirable to allow these for certain languages, and if not, why is enPR more desirable for English sections? Thadh (talk) 17:02, 13 May 2022 (UTC)[reply]

I think all enPR transcriptions should be removed. The IPA is the sole, universally recognized, standard phonetic transcription scheme; and I can neither read any other phonetic alphabets, nor do I want Wiktionary to include any non-universal / regional phonetic alphabets. ·~ dictátor·mundꟾ 22:45, 14 May 2022 (UTC)[reply]

Problem is a lot of people don't like IPA. It gets uglier the further away you get from Western European languages, and many academic books use non-IPA alphabets. Some languages having more specialized transcription alphabets alongSIDE IPA would add to a page, not take away, so the potential loss is 0, while our gain is proving information that someone might want to look up as they are reading certain textbooks. We shouldn't narrow ourselves down in the same of a quasi-universal alphabet that, while useful, is not actually that universal or even well liked. Vininn126 (talk) 10:19, 15 May 2022 (UTC)[reply]

It is critical that enPR stays for now, given that our IPA transcription practices for English are wildly inconsistent, making them markedly inferior to enPR for the end user. For instance, the RP trap vowel is transcribed as /æ/ in some entries and /a/ in others (in my view, the latter is superior, as it more accurately reflects contemporary RP pronunciation; we shouldn't let historical transcriptional practices tie us down like millstones). The ideal solution would be to develop a consistent transcription scheme that accounts for different varieties when reasonable; details about realisational variation within varieties can be included in an appendix. For instance, Mary had a little lamb could be transcribed as /ˈmɛːɹi had ə ˈlɪtəl lam/ for RP, ˈmɛɹi hæd ə ˈlɪtəl læm/ invalid IPA characters (/) (with a variant /ˈmɛɚi-/) for GA, and something like /ˈmæːrɪ hæd ə ˈlɪtəl læm/ for Early Modern English. We can acknowledge that some RP speakers may say /ˈmɛəɹi/ or /læm/ in appendixes, but such pronunciations would be avoided on our entries as they present a baffling inconsistency to the individual who lacks enough knowledge of English transcription practices to intuit that the /æ/ in some entries and the /a/ in others refer to the same thing. Hazarasp (parlement · werkis) 11:36, 15 May 2022 (UTC)[reply]

I think the idea is fine, as long as a key is given for readers. I am not aware of any previous consensus-based discussion/vote which specifically disallowed phonetic alphabets other than IPA and enPR, so I can't see the point of this BP discussion seeking to allow them or overturn such a disallowance. Ultimately, a community would be discussing on allowing any particular proposed phonetic alphabet for particular language(s) and consensus withing community would be needed to start using it, which might as well be done now. If anyone (such as Inqilabi, per above comment) wants to strictly ban non-IPA phonetic alphabets Wiktionary-wide, they need to gain consensus for that, since that is also not the status quo now. —Svārtava (t/u) • 16:08, 24 May 2022 (UTC)[reply]

I guess none of y'all were around when we unanimously banned SAMPA in 2013. The issue was that it's just IPA for someone without an IPA keyboard, so it was filling pronunciation sections with redundant and ugly transcriptions.

Looking at something like Uralic Phonetic Alphabet, I think it could be pretty confusing to include this on a page but not include IPA, so my stipulation for embracing other PAs is that they should be accompanied by IPA. It's hard enough to learn one phonetic alphabet! At least we're consistent now (outside of English). I'm not sure how to feel about enPR. Ultimateria (talk) 17:00, 24 May 2022 (UTC)[reply]

Hopefully a key would help this, at least. I can see someone who knows nothing about it being somewhat confused, so accomponying IPA might not be a bad stipulation, unless it's somehow exclusive to smaller languages. Vininn126 (talk) 17:29, 24 May 2022 (UTC)[reply]

Why should we include UPA? We should use one phonetic alphabet, and IPA seems like the only realistic choice. Is there an argument for UPA for certain languages commonly described in it? Maybe, but I'd like to see it directly argued for that combination. IPA may not be the best, but the fact that an academic can choose a different system for their book does not mean that we should include many different systems for our book. Even as a supplement to IPA, it makes more noise, more confusion, more change for stuff that would be clear errors or vandalism in IPA to hide because few can read the other system.--Prosfilaes (talk) 03:53, 27 May 2022 (UTC)[reply]

Why should we use one? What is the downside to having multiple together? You ask why we should include others, which is explained above. You have not provided a counter argument why only one should be used. Above is directly states that these alplhabets would go alongside any IPA transcriptions. The one downside is that it does generate more text, however I think this is a separate issue plaguing pages anyway, we need a way to be able to hide or show content. Vininn126 (talk) 10:18, 27 May 2022 (UTC)[reply]

Vininn126 (talk) 09:12, 27 May 2022 (UTC)[reply]

Hello!

Have you noticed that some wikis have a different desktop interface? Are you curious about the next steps? Maybe you have questions or ideas regarding the design or technical matters?

Join an online meeting with the team working on the Desktop Improvements! It will take place on 17 May 2022 at 12:00 UTC and 19:00 UTC on Zoom. Click here to join. Meeting ID: 86217494304. Dial by your location.

Agenda

• Update on the recent developments
• Questions and answers, discussion

Format

The meeting will not be recorded or streamed. Notes will be taken in a Google Docs file. Olga Vasileva (the Product Manager) will be hosting this meeting. The presentation part will be given in English.

We can answer questions asked in English, Italian, Polish; also, only at the first meeting: Farsi, Vietnamese; only at the second meeting: Portuguese, Spanish, Russian. If you would like to ask questions in advance, add them on the talk page or send them to sgrabarczuk@wikimedia.org.

At this meeting, both Friendly space policy and the Code of Conduct for Wikimedia technical spaces apply. Zoom is not subject to the WMF Privacy Policy.

We hope to see you! SGrabarczuk (WMF) (talk) 05:02, 14 May 2022 (UTC)[reply]

@Justinrleung, Fish bowl, 沈澄心 Should the Chaozhou iəm rime be written as "iam" in Peng'im? 新潮汕字典 and czyzd.com write it as "iam", while mogher.com writes it as "iem". RcAlex36 (talk) 09:39, 14 May 2022 (UTC)[reply]

@RcAlex36: I think we should follow 新潮汕字典 and write it as iam. — justin(r)leung _{{ (t...) | c=› }} 17:27, 14 May 2022 (UTC)[reply]

Do terms like English proliferation whence a new term arises (proliferate) merit a synchronic analysis (proliferate + -ion) ? ·~ dictátor·mundꟾ 22:32, 14 May 2022 (UTC)[reply]

Probably not. You could, instead of that, write into the etymology section that thereafter the word “proliferate” was back-formed, so that having both would be an outright contradiction, though it be possible to make the same statement about back-formation more discretely by only listing it in the derived terms section and thus make the article gainsay itself less obviously; for Arabic I have written more often into etymology sections that a verb or certain or all verbs are denominal and also that the supposed root is denominal (also averting that people falsely disbelieve the etymology due there appearing a native root), and having a root entry often makes man forgo a derived terms section, the root listing being an alternative to a derived terms section with the fact of certain words being derived terms sufficiently stated by Wiktionary in the etymology section of the term from which the derived terms are derived. Fay Freak (talk) 22:43, 14 May 2022 (UTC)[reply]

We have some quotations in our entries that are taken from Wikipedia, e.g., at corresponding. I don't think that adding quotes from WP is a nice idea. What’s your opinion, folk? ·~ dictátor·mundꟾ 01:36, 16 May 2022 (UTC)[reply]

It is highly discouraged. Vininn126 (talk) 14:08, 16 May 2022 (UTC)[reply]

In that particular example, there is simply no justification whatsoever. Also, why is there audio? for the "citation"? DCDuring (talk) 15:47, 16 May 2022 (UTC)[reply]

The audio sounds auto-generated and was uploaded by a Korean, so there is no issue with removing that as we also discourage non-native audios, not to speak of computer voicing. Fay Freak (talk) 18:00, 16 May 2022 (UTC)[reply]

So should we remove them? ·~ dictátor·mundꟾ 17:33, 16 May 2022 (UTC)[reply]

We don't usually remove nondurably archived quotes, though they don't count for attestation.

OTOH, making an explicit exclusion for all WMF projects (or even all wikis) sounds like a good idea to me. DCDuring (talk) 18:51, 16 May 2022 (UTC)[reply]

My policy is to remove quotes which are not useful for attestation (e.g. mentions and in-text definitions) and move them to the citations page if they are helpful in understanding the meaning ignoring our policies for attestation. In this case I would delete it since it doesn't do anything. - TheDaveRoss 12:10, 18 May 2022 (UTC)[reply]

@The DaveRoss Assistance in comprehension should not be exiled to the citation page. We should maintain the pretence that Wiktionary is meant to be useful. (As a side point, have we any clue as to whether Wiktionary earns its keep?) --RichardW57m (talk) 13:53, 27 May 2022 (UTC)[reply]

In-text definitions can be helpful in some cases, especially where many people's usage is determined by these definitions. --RichardW57m (talk) 13:53, 27 May 2022 (UTC)[reply]

@HappyMidnight contributed numerous citations to English entries that don't seem durably archived and contain {{audio}}. Can we speedily delete:

1. the uses of {{audio}}, for which there is no provision in WT:ELE?
2. the non-durably archived citations?

If such uses of {{audio}} can't be speedily deleted, do we need some changes in WT:ELE to either outlaw or encourage the use of {{audio}} for citations? Can we save time by removing the "citations" en masse given the pattern of poor contribution quality or do we have to evaluate each citation and possibly use the RfV process?

Is this something that should be handled via WT:RFC? DCDuring (talk) 16:02, 16 May 2022 (UTC)[reply]

I don't hate the idea of {{audio}} for quotes (when they are freely licensed, like LibriVox recordings of public domain books). It seems like the kind of thing that an end user could potentially appreciate, especially if it was for a language they didn't know well or a word with tricky pronunciation. But having it on only a tiny number of quotations makes it stick out like a sore thumb and seem like inconsistent formatting. And in the example on corresponding the audio isn't even the same as the text, one uses "derived" where the other has "derivative". It also would make it harder if someone later decides they want to add more context to a quote or something, because now they also have to change the audio or remove it. 98.170.164.88 16:34, 16 May 2022 (UTC)[reply]

It doesn’t stick out, I haven’t noticed it until DCDuring mentioned it. And it can be appreciated; the layout makes sense, though one might imagine a better one. I had played with the thought of voicing some quotes, too, as it is less boring than individual words – or I obviously like to hear myself talking, the more prolixly the better, and I imagine that others would too. Fay Freak (talk) 18:06, 16 May 2022 (UTC)[reply]

Of course one wouldn't notice it: The user only inserted it in about 100 entries. DCDuring (talk) 18:43, 16 May 2022 (UTC)[reply]

 [[:|Wiktionary:Tea room/2022/May § now playing]]
This page is a soft redirect.

Starting about two weeks ago, an unregistered user began adding Tiberian Hebrew narrow IPA transcriptions based on the work of Geoffrey Khan. For reference, some IPs used by this user include 1, 2, 3, 4, 5, 6, 7, 8, 9, 10. Earlier today Rebfeee (talk • contribs) reverted several of these Tiberian edits without any prior discussion or edit summary explanation. When I asked about it on their user talk page, Rebfeee responded by stating that the Tiberian Hebrew edits were unsourced and inaccurate.

To take one specific example, prior to all of this אלוהים had a Tiberian IPA of [ɛloːˈhiːm]. The IP user modified this to [ʔɛ.loːˈhiː.ĩm], which appears to be more consistent with, but perhaps not identical to, the transcriptions given in Khan's The Tiberian Pronunciation Tradition of Biblical Hebrew (see page 615 in this PDF, which has [ʔɛloːˈhiːim]). This is a large, two-volume open access work so maybe they took it from a different part; or maybe from a different work by Khan altogether. In any case, Rebfeee reverted it back to [ɛloːˈhiːm].

I don't know enough to judge what's going on here exactly, e.g. maybe there is actual scholarly debate over Tiberian Hebrew pronunciations, or disagreement about how narrow we want to be in transcriptions. It seems to me that both parties are editing in good faith, but it would be good for someone to take a look at this. 98.170.164.88 21:47, 22 May 2022 (UTC)[reply]

Hello all,

The Universal Code of Conduct (UCoC) project team has completed the analysis of the feedback accompanying the ratification vote on the Universal Code of Conduct Enforcement Guidelines.

Following the completion of the UCoC Enforcement Guidelines Draft in 2022, the guidelines were voted on by the Wikimedian community. Voters cast votes from 137 communities, with the top 9 communities being: English, German, French, Russian, Polish, Spanish, Chinese, Japanese, Italian Wikipedias, and Meta-wiki.

Those voting had the opportunity to provide comments on the contents of the Draft document. 658 participants left comments. 77% of the comments are written in English. Voters wrote comments in 24 languages with the largest numbers in English (508), German (34), Japanese (28), French (25), and Russian (12).

A report will be sent to the Revision Drafting Committee who will refine the enforcement guidelines based on the community feedback received from the recently concluded vote. A public version of the report is published on Meta-wiki here. The report is available in translated versions on meta-wiki. Please help translate to your language

Again, we thank all who participated in the vote and discussions. We invite everyone to contribute during the next community discussions. More information about the Universal Code of Conduct and Enforcement Guidelines can be found on Meta-wiki.

On behalf of the Universal Code of Conduct project team --Mervat (WMF) (discuss • contribs) 21:39, 23 May 2022 (UTC)[reply]

I don't think this meets the standards we should be attaining, if I'm honest. It's an assertion that a term or sense is used by some dialect, but how can we possibly say that while neglecting to mention which? It raises the obvious question of how we can justify making that claim in the first place.

Worse, given how loaded the term dialect can be at times (sense 3 - "language that is perceived as substandard or wrong"), it may be used by certain editors in place of terms like "slang" or "informal", or as a way to covertly say "vulgar", "lower class" or "rustic". Without any information on which dialect it's referring to, it's very difficult to know what the editor actually meant by it. Often, it may not even be intentional, but that's precisely the issue with a term so open to interpretation as this one.

I just wanted to gauge opinions on this, as I feel like it would be good to go over a lot of these terms and do them properly. Theknightwho (talk) 15:05, 27 May 2022 (UTC)[reply]

It's not always possible to asign a word to a specific dialect, and even if it were possible, it's often not a good idea to be so specific, especially with large languages. Thadh (talk) 15:47, 27 May 2022 (UTC)[reply]

Barring edge cases with limited documentation languages, it's going to be possible to narrow the term down to a region or specific group of people. If it isn't, then I'm unsure what basis we have for claiming it's dialectal in the first place. It's not coherent. Theknightwho (talk) 16:15, 27 May 2022 (UTC)[reply]

What about words which are present in several regions but not all? Hypothetical example, but would you like us to use a long label like (Connecticut, Alaska, Cornwall, Canberra, Kilkenny)? This situation may be rare, though. 70.172.194.25 16:21, 27 May 2022 (UTC)[reply]

That is a legitimate issue that does need addressing, though it's a much broader issue than this conversation (e.g. entries that should, by rights, have something like Commonwealth of Nations, Ireland, India, Pakistan ...). However, I'm struggling to think of any instances where "dialectal" is a genuinely appropriate label. At least a label like the one you've suggested conveys useful information, whereas "dialectal" could mean anything from "regional" to "archaic" to "nonstandard" depending on the editor. Theknightwho (talk) 16:31, 27 May 2022 (UTC)[reply]

The problem is that a word may be distributed along the edges of a language's distribution (e.g. archaic words following the wave model), in which case you can't speak of a region or specific groups of people. Instead, you speak of standard and non-standard, but since non-standard itself includes also slang and jargon, you can narrow it down to "pertaining to several regions not related to each other, but also not part of the standard language" a.k.a. dialectal. Thadh (talk) 20:39, 27 May 2022 (UTC)[reply]

You can call the term dated or archaic. It's not dialectal unless it's actually part of a dialect, but if it's just old-fashioned then we already have terms to deal with that. If it pertains to several regions, then the obvious solution is to name those places - which is exactly what we do already for terms that are only generally used by people in or from those places. Calling it "dialectal" conveys no information that wouldn't be better conveyed by saying something else. It's simply not used consistently or coherently:

• At bairnless it seems to mean either "colloquial" or "dated", potentially glossing over the existence of Scots as well.
• At gash (etymology 2) it's definitely being used to imply "vulgar" - which it is, I can confirm as someone from Northern England. You wouldn't say "that's gash" to your nan.
• At took it's a covert way of saying "nonstandard", while avoiding the fact it's usually interpreted as a misconstruction.
• At bootiful it conveys absolutely no information whatsoever. Is it some kind of reference to stereotypical Cockney? Who knows!?

Theknightwho (talk) 21:00, 27 May 2022 (UTC)[reply]

You're not understanding me. I'm talking about dialects that didn't undergo an innovation, and as such are everywhere. Take a look at this: [5]. huus and muus are the original variants, diphthongation to huis and muis is innovation. You can't classify this into dialects or regions, it's all over the place! Thadh (talk) 21:02, 27 May 2022 (UTC)[reply]

It's not that complicated to name four or five regions. Theknightwho (talk) 21:05, 27 May 2022 (UTC)[reply]

What about twenty? That's not uncommon in most languages. Thadh (talk) 21:44, 27 May 2022 (UTC)[reply]

There are ways of handling these kinds of issues. See 米#Synonyms, which deals with 80. Theknightwho (talk) 21:54, 27 May 2022 (UTC)[reply]

• In Japanese, there is a strong government-imposed sense of what is "standard" Japanese, and in Japanese lexicography, "dialect" is definitely a thing. The label is quite useful for us working with Japanese, and I cannot agree with any proposal to deprecate this. ‑‑ Eiríkr Útlendi │^{Tala við mig} 21:29, 27 May 2022 (UTC)[reply]

  This only adds to the point that the term has no consistent meaning. "Dialect" is a common term in Chinese lexicography as well, but that's handled by actually specifying what the dialects are, which is the point. Theknightwho (talk) 21:32, 27 May 2022 (UTC)[reply]

The meaning is context-dependent -- indeed, like most words.  :) ‑‑ Eiríkr Útlendi │^{Tala við mig} 22:16, 27 May 2022 (UTC)[reply]

I've mentioned it above, but what do you think of the way this issue is handled at 米#Synonyms (which should take you to the Chinese dialectal synonyms table)? Theknightwho (talk) 22:23, 27 May 2022 (UTC)[reply]

Side note, but the title "dialectal synonyms" for that table has always rather irked me. It was used in Korean too until I brought up that it covers much more than dialects and now we use "Historical and regional synonyms" (see: 가위#Synonyms (gawi) & also 가새 (gasae) which also uses the "dialectal" label in a useful way) which feels much more accurate in this case as well, without falling into sociolinguistic & political issues. (Notifying Atitarev, Tooironic, Fish bowl, Justinrleung, Mar vin kaiser, RcAlex36, The dog2, Frigoris, 沈澄心, 恨国党非蠢即坏, Michael Ly): AG202 (talk) 23:49, 27 May 2022 (UTC)[reply]

China also defines standard Mandarin as the standard form of spoken Chinese that everyone is expected to learn in school. Formal written Chinese is based on standard Mandarin, even in Hong Kong where Mandarin is not widely spoken. I know Taiwan just changed their constitution to designate the other variants of Chinese spoken in Taiwan like Hokkien and Hakka to be official languages, but everyone still learns the Taiwanese version of standard Mandarin in school and uses it as the lingua franca. The dog2 (talk) 03:30, 28 May 2022 (UTC)[reply]

I do think calling the synonyms "historical and regional" might be a little better for the Chinese context as well. As for what "dialectal" means for Chinese, it is generally used for any term that is not considered to be part of Standard Mandarin but still used in modern varieties. I do prefer using the particular labels (e.g. "Cantonese", "Min Nan") but when there are too many to list and if it's a widespread word, I generally just use "dialectal" (and let people check the synonyms table). There is also another issue of "dialectal X" (e.g. "dialectal Cantonese", "dialectal Hakka", etc.), which is slightly more problematic. For Cantonese, it is perhaps less controversial as to what "Standard Cantonese" is, but it's not as straightforward for other varieties. The status quo seems to be respective to what we have chosen as representative dialects for the particular groupings in {{zh-pron}} (Nanchang for Gan, Changsha for Xiang, etc.) — justin(r)leung _{{ (t...) | c=› }} 04:02, 28 May 2022 (UTC)[reply]

In principle, I strongly agree we should specify what dialects a term is used in rather than just saying "dialectal". In practice, there are practical limitations, which people have brought up in past discussions and again above. I think we should make a concerted effort to improve (replace) the label wherever possible (especially in cases where the dialects are already listed, e.g. "US, dialectal, Virginia, Maryland" → "Virginia, Maryland"), and then see what's left, as far as whether there is anything the label needs to be retained for. Another issue: "dialectal" and "regional" overlap and it's haphazard which one entries are labelled with (some entries have both labels on different senses, for no apparent or maintainable rhyme or reason, e.g. trounce). - -sche (discuss) 06:15, 28 May 2022 (UTC)[reply]

Hello all,

I’d like to share an update on the work on the Enforcement guidelines for the Universal Code of Conduct.

In 2022 May, the Universal Code of Conduct (UCoC) project team completed a report on the 2022 March ratification vote about the guidelines. Voters cast votes from at least 137 communities. At least 650 participants added comments with their vote. A report is available on Meta-Wiki. (See full announcement)

Following the vote, the Community Affairs committee (CAC) of the Wikimedia Foundation Board of Trustees asked that several areas be reviewed for improvements. A Revision Drafting Committee will refine the enforcement guidelines based on community feedback.

To help the Revisions committee, input from the community is requested. Visit the Meta-wiki pages (Enforcement Guidelines revision discussions, Policy text revision discussions) to provide thoughts for the new drafting committee. (See full announcement)

Let me know if you have any questions about these next steps. --Mervat (WMF) (talk) 07:25, 28 May 2022 (UTC)[reply]