Wiktionary:Beer parlour/2022/May

discussion rooms: Tea room • Etym. scr. • Info desk • Beer parlour • Grease pit ← April 2022 · May 2022 · June 2022 → · (current)

---

Links in Template:lb to WP and entries, not glossary

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

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)

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)

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)

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)

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

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)

While I agree that it would be good to have more glossary entries, I would oppose yuor general suggestion of removing WP links altogether. There are plenty of topic categories which don't belong in the glossary, and where WP is a far more useful link than our entry. In some cases we may not have an entry at all, or it wouldn't be very helpful, e.g. (international standards), which is used on things like ISO and IATA codes. Theknightwho (talk) 14:18, 8 June 2022 (UTC)

Even that article is somewhat long. Also, I believe that a link to a different project is slower than a same-project link. For those with slow internet connections, such extra delay may just reduce the value of Wiktionary. DCDuring (talk) 17:43, 8 June 2022 (UTC)

Editing news 2022 #1

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

New editors were more successful with this new tool.

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)

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)

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)

Using Cyrillic script for Mariupol Greek primary forms

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)

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

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)

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)

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)

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

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)

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

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)

What apostrophe does French use?

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)

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)

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

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

Tawellemmet Tamajeq language code

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)

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)

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

@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":

• Tuareg (tmh)Collapse
  • ├──── Ghat (tmh-ght) E
  • ├──── Tamahaq (thv) E
  • ├──── Tamasheq (taq) E
  • ├──── Tawellemmet (ttq) E
  • └──── Tayert (thz) E

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)

The Lemmatization of Alt Forms

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)

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)

@Thadh: The lemma v. non-lemma distinction can be used as a stand-in for possessor of inflection table v. inflected form. I think that at some point I should review the inflections of the extreme Lao-repertoire Lao script Pali nouns and adjectives. (By extreme I mean that, apart from diacritics, the notations for syllable codas are restricted to those used in Lao.) The simplest method is to work through the three categories of Pali masculine nouns, neuter nouns and adjectives, jump to the Lao script section via the categoryTOC template, and process each lemma compatible with the extreme Lao-repertoire writing system. Some of the suggestions here would further complicate the process of iteration I've just described. --RichardW57m (talk) 10:10, 22 June 2022 (UTC)

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)

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)

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)

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)

adam kilgarriff prize

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

Jogi language code not working

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)

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

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)

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

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

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

Wiktionary portal (https://wiktionary.org) has changed

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)

Unwieldy category lists

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)

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)

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)

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)

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)

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)

Wikimedia Foundation Board of Trustees election 2022 - Call for Election Volunteers

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)

General Maintenance Bot

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)

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)

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

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)

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)

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)

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

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)

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

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)

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

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)

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)

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)

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

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)

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)

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)

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)

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

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)

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)

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

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)

Pop Slang

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)

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)

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

I suggest we deport anybody caught speaking slang, to the Moon. Equinox ◑ 04:37, 5 July 2022 (UTC)

Phonetic alphabets

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)

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)

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)

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/ (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)

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)

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)

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)

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)

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)

I did include a counter argument. Everything on the page should convey something, and if IPA conveys the information, a new phonetic system conveys nothing. For non-linguistic readers, our pages are confusing enough, and phonetic alphabets are a particularly confusing part. I generally need to look up vowels, and any consonants outside the basic Western European set. Having two sets of phonetic alphabets will make it even more confusing for our readers. For what? Nobody has expressed any reason to do this. There's no evidence any significant number of English speakers know UPA.--Prosfilaes (talk) 23:03, 28 May 2022 (UTC)

So we should ignore the fact many academic works use these alphabets? Also, to the argument of bloat - I believe the bigger issue is not being able to hide information. Vininn126 (talk) 15:44, 29 May 2022 (UTC)

Is that a fact? The English Wikipedia lacks English cites for UPA, besides Unicode; the French Wikipedia has one, but that's comparing it, not using it. For an English speaking audience, UPA is useless. AA has been mentioned on this thread; w:AA offers no help on what that means. I guess w:Americanist phonetic notation was meant? Of which that page shows there are many, many, many alternatives and no standard. For an English speaking audience, there doesn't seem to be anything approaching IPA as a consistent standard.

There is an argument for alternate phonetic alphabets, if they were default hidden. They're still a source of spam and vandalism, perhaps worse as they're default hidden, and they're, if anything, more useless, as they're only visible to users who know enough to turn visibility on. In any case, that's not the discussion we're having; fix the underlying problems before asking for things that exacerbate the underlying problem.

If this has been "we have phonetic data for language X in system Y, and everyone who knows language X knows system Y", I wouldn't be objecting. Instead it was "why don't we add a bunch of random systems", and that's because having random phonetic systems on random entries doesn't improve us at all. I might argue that we should default hide entries in languages with less than X entries, but that's more core; we're here to record languages, not phonetic systems.--Prosfilaes (talk) 23:16, 29 May 2022 (UTC)

"The Semitic Languages (2nd Edition) by John Huehnergard and Na‘ama Pat-El" uses a Semitic Phonetic Alphabet alongside IPA. "The Uralic Languages by Daniel Abondolo" uses an Uralic one. "The Slavonic Languages (Routledge Language Family Series) by Bernard Comrie" uses a Slavonic one. Not to mention that even just most PIE page names are not IPA. AS is used on pl.wiktionary. If your issue is with bloat, I can agree and we should come up with ways to reduce that, but I don't see it as an argument against this, as these alphabets are, indeed, often used either alongside or entirely instead of IPA. A lack of it on Wikipedia is not actually a sign as to whether it is used there or not. The idea of making many things default hidden is actually something I think we should be toying with, but that's a thread I want to start next month. Vininn126 (talk) 08:08, 30 May 2022 (UTC)

I oppose using a Semitic phonetic alphabet, or a Uralic, or a Slavonic one. We should only use standard alphabets, of which IPA and UPA seem to be alone in being.--Prosfilaes (talk) 17:50, 30 May 2022 (UTC)

These are standard within their given field? Vininn126 (talk) 17:54, 30 May 2022 (UTC)

I refer you to w:Americanist phonetic notation. There's a general pattern, but each author uses a slightly different set of rules specific to them.--Prosfilaes (talk) 21:57, 30 May 2022 (UTC)

That's in English. Also, there's variation within IPA transcriptions as it is, different dictionaries notate the same language different ways. So by that logic, we shouldn't have IPA. Vininn126 (talk) 21:59, 30 May 2022 (UTC)

I would like to note that although we are a wiki written in English that doesn't mean we have to cater only to people that are monolingual English speakers. I personally think the English wiktionary is of a much higher standard and much more useful than our sister projects, and I don't see why a Finnish person only familiar with UPA and interested in Votic, for instance, has to learn IPA in order to understand our entries. Thadh (talk) 12:02, 30 May 2022 (UTC)

I don't see this proposal changing that. A Finnish person only familiar with UPA and interested in Votic is not likely to find many if any improvements coming from us throwing the doors open to any and all phonetic alphabets. If someone specifically comes in to add UPA to Votic, then fine, but throwing the doors open is going to get a few random additions that will be of no help to anyone.--Prosfilaes (talk) 17:50, 30 May 2022 (UTC)

Let's talk about the Desktop Improvements

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)

Teochew -iam

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

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

Surface analysis & back-formation

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)

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)

Quoting from Wikipedia

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)

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

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)

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)

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

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)

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)

@TheDaveRoss 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)

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)

I agree, but mentions are not helpful in demonstrating how a word is used, which is the point of usage examples. Instead they add clutter to the main entry. Adding many quotes to the entry, especially those which are not valid for CFI, does not make Wiktionary more useful, it makes it harder to find the useful information instead. Also, if you feel that usefulness is merely a pretense here, why do you bother to contribute? - TheDaveRoss 17:34, 8 June 2022 (UTC)

I agree. I think we have general consensus on this. Do we need to confirm that consensus? DCDuring (talk) 17:48, 8 June 2022 (UTC)

Agreed. More =/= better. Vininn126 (talk) 17:59, 8 June 2022 (UTC)

If possible, remove and replace with "real" citations (books etc.) when you find them. Equinox ◑ 17:53, 8 June 2022 (UTC)

template:audio in citations

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

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)

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)

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

now playing

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

Dispute over Tiberian Hebrew pronunciations

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)

IMO User:Refbeee is correct and the IP is wrong. Those narrow transcriptions look very strange to me and are certainly not the consensus of the field. Benwing2 (talk) 21:31, 30 May 2022 (UTC)

Oops, should be User:Rebfeee. Benwing2 (talk) 21:32, 30 May 2022 (UTC)

Report on Voter Feedback from Universal Code of Conduct (UCoC) Enforcement Guidelines Ratification

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)

Deprecating the use of "dialectal" in labels

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)

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)

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)

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)

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)

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)

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)

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)

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

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

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

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

  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)

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

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)

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)

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)

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)

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)

Next steps on the Universal Code of Conduct (UCoC) Enforcement guidelines

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)

Gender for surnames

In some languages, the surnames may be male or female or common gender. (Template_talk:surname#Gender). Template:given name produces Categories:XX male given names with a parameter |male. Example: At the moment, all the Category:Greek surnames are in fact Greek male surnames and all have a corresponding fem.surname (which are indeclinable). There are some common gender sunames as well.(At el.wikt, Male surnames, Fem & Common) At template {{surname}}, i cannot find such a parameter. Should we create these Cats manually at the bottom of the pages? Thank you. ‑‑Sarri.greek ^♫ I 15:20, 28 May 2022 (UTC)

Not manually, no; this functionality should definitely be added to the template, like it's in the given-name template. In Icelandic too (and various other languages) you have female vs male surnames (Jónsdóttir, Jónsson), and some unisex / common-gender surnames (Bernhöft, Hjaltested). - -sche (discuss) 15:28, 28 May 2022 (UTC)

User:Sarri.greek, I added support for a gender parameter, tentatively g=. Let me know if there are problems. It does not categorize yet, but it probably should. It is possible we might want to restrict what values can be passed to it (compare given names), or throw an error if it's used on certain languages like English. - -sche (discuss) 17:01, 22 June 2022 (UTC)

Thank you so much @-sche. I shall try it for Category:Greek surnames and let you know. I understand the difficulry corresponding Cats. at languages with mainly default common gender surnames. ‑‑Sarri.greek ^♫ I 17:06, 22 June 2022 (UTC)

@-sche, it is a bit complicated, and probably an editor has to coordinate the surnames in all languages. As for Cat:Greek surnames, we do not intend to add more, so, it does not matter how the Categories could be formed for the moment.

Category:Surnames and Category:Surnames by language include an index for each language, but it is not stated which languages do not have male and female surnames. We also assume they are all proper nouns.

Even for languages with genders, but not for surnames (for example Cat:Italian surnames like Agnetta, Cat:French surnames like Abeille), the headword templates at the entries are missing gender (at least for some examples checked).

According to the names of Categories of Category:Given names by language i see that en.wiktionary uses the words 'male', 'female' and 'unisex' for masculine, feminine and common gender equivalents of proper noun genders.

• For languages with no genders or inflection of surnames: the Category:Xxxx surnames e.g. Category:English surnames is equivalent to Unisex surnames by default.
  • For transliterations: e.g. Pavlov Pavlova Ι see a different template: {{name translit|en|ru|Па́влова|type=surname}} no categories like Cat:English foreign female surnames are added. These transliterations are potentially endless in all languages and I think a Wiktionary:Entry_layout#Part_of_speech Transliterations could be available, otherwise, Proper nouns might be flooded with foreign names. (the PoS 'Romanization' is not applicable for e.g. Greek, where we need the reverse kind of translit).
• For languages with genders and/or inflection of surnames we have (for example Greek, Russian) Cat:Greek surnames the headword Templates for proper nouns should take care of the gender, so, there is no need for gender subcategories (which are potentially huge)
  • e.g. Cat:Greek male surnames like Παρασκευόπουλος, Cat:Greek female surnames (like Παρασκευοπούλου, Cat:Greek unisex surnames like Ματθαίου,
  • plus transliterations like Κένεντι (Kénenti)

Sorry to bother you, they are too few. Let's forget it. ‑‑Sarri.greek ^♫ I 19:52, 22 June 2022 (UTC)

Just on terminology of genders. "Common gender" is a grammatical gender |g=c, e.g. in Swedish, Danish. It's sometimes used for Dutch and Norwegian because many nouns have both masculine and feminine genders or the difference becomes subtle or disappearing. For languages where the difference between masculine and feminine is clear but nouns (including proper nouns, names) can belong to both/either genders, I wouldn't use "common" gender but masculine + feminine, i.e. two genders. I am sure this will be applicable to Greek as well. E.g. Ματθαίου (Matthaíou) has the wikicode {{el-noun-proper|m|ind|g2=f}}, indicating that the surname is applicable to both masculine and feminine genders. "Unisex" doesn't seem like a grammatical term, in my opinion. --Anatoli T. ^{(обсудить}/^вклад) 07:07, 23 June 2022 (UTC)

Thank you Anatoli T. I just followed the terms (unisex) as in Category:Given names by language. The expression 'of common gender' is usual in greek, ancient and modern, referring to living beings. A masc or fem noun example, could be ἄκανθος (ákanthos). ‑‑Sarri.greek ^♫ I 09:55, 23 June 2022 (UTC)

@Benwing2 or anyone else: can you make the template categorize according to gender when one is declared? I don't think it makes sense to add the categories manually when it's something the template could do, and something the given name template already does. As for whether to call them "unisex" or "common-gender" surnames, I suppose that whereas "unisex" is more common in English in reference to given names (since English natively has many), "common-gender" may be more common in reference to surnames. (Of course, it has to be "common-gender surnames" because just "common surnames" is something else!) - -sche (discuss) 23:53, 4 July 2022 (UTC)

@-sche I've been meaning to Lua-ize {{surname}} for awhile and clean it up to do things like this. Should be able to get to this in a couple of days. Benwing2 (talk) 03:59, 5 July 2022 (UTC)

I appreciate that. BTW: I tentatively named the gender parameter "g=" when I added it last month, but if there's a better/standard name for it (e.g. I see the given name template uses "gender="), by all means rename it. - -sche (discuss) 04:22, 5 July 2022 (UTC)

Use of Votes to settle Requests for verification requests

Recently, @Kiwima started two votes on whether the citations provided in two individual entries are, or not, acceptable: Wiktionary:Votes/2022-05/FaCIAbook validation and Wiktionary:Votes/2022-05/elfism validation. These two votes were followed by another three: Wiktionary:Votes/2022-05/troid validation, Wiktionary:Votes/2022-05/sin flattening validation, and Wiktionary:Votes/2022-05/melanoheliophobia validation. These votes are unnecessarily specific (I believe the voting system should be used to establish broad rules, not discuss individual entries), but also create a dangerous precedent, since it's yet unclear if a positive or negative outcome will superseded the established policies of Wiktionary:Requests for verification and Wiktionary:Criteria for inclusion. I see two possible problems here: either the previous two policies are not clear enough, either in their rules or in their enforcement, and thus they need to be discussed, clarified and voted upon; or the voting system is being abused, creating a constitutional or procedural crisis, and thus I believe we need some stronger standards for the proposal of votes with a clearer description of what would be the effects of the votes. I would like to note that it's not the first time that reckless votes create such crises. Another example would be Wiktionary:Votes/2021-04/Creation of Template:inh+ and Template:bor+ and Wiktionary:Votes/2021-08/Nullifying the previous templates vote whose consequences were often not clear to the community. - Sarilho1 (talk) 09:37, 29 May 2022 (UTC)

I also move that these be moved over to RFV and that all future such issues be settled in RFV, not by votes. Vininn126 (talk) 10:51, 29 May 2022 (UTC)

I concur; votes are not the place to discuss individual entries. PUC – 10:54, 29 May 2022 (UTC)

Agreed on all counts, though overcompensation by establishing byzantine, overelaborate strictures regarding votes is a real risk here; we need to ensure that anything that emerges from this is succinct, clear, and flexible. Hazarasp (parlement · werkis) 13:04, 29 May 2022 (UTC)

You are absolutely right. That's also why I wanted to open a discussion on what problems are we facing rather than trying to propose a some set of rules that might be completely inadequate. - Sarilho1 (talk) 12:04, 3 June 2022 (UTC)

I also agree. I'd favor creating a new forum, or at least carve out a space in RFV, to handle these entries. Imetsia (talk) 17:47, 29 May 2022 (UTC)

That's an interesting idea. I'm not sure it's necessary, but if it ends up being so, then something like that would definitely be a good idea. Vininn126 (talk) 17:49, 29 May 2022 (UTC)

I definitely think creating votes for individual words is a problem. This should be settled in RFV or RFD. Andrew Sheedy (talk) 21:05, 29 May 2022 (UTC)

As I commented on one of the votes, these votes are in response to the recently-added second dot point at WT:CFI#Attestation. The votes are in a way subordinate to the RFV discussions currently in process, and will be used to confirm whether sources we haven't conventionally accepted for attestation purposes may nonetheless be used to verify the words in question. CFI doesn't demand that votes be used, so another discussion-based process could be used instead, perhaps at TR or at RFVE itself. This, that and the other (talk) 07:28, 30 May 2022 (UTC)

These votes are a clear indication that we need to stand up on our hind legs and vote on what online sources we will accept as durably archived attestation. We may need to incorporate the Wayback Machine at the Internet Archive, Wikisource, etc. into our system and technically facilitate their use. DCDuring (talk) 13:39, 30 May 2022 (UTC)

I agree. Somehow getting Wikisource involved is a very interesting idea. Vininn126 (talk) 13:40, 30 May 2022 (UTC)

I would agree with that so long as we are restricting use of Wikisource to fully proofread articles. There are tons of scannos in even the moderately reviewed pieces. bd2412 T 22:20, 30 May 2022 (UTC)

We deal with scannos at Google. Is Wikisource worse? If it is, then we may have to limit ourselves to IA and other sources that are at least as well-funded (ie, likely to prove relatively durable) as they are. Are there any other candidate archival sources for Web material? DCDuring (talk) 23:59, 30 May 2022 (UTC)

Wikisource is never going to be worse, and in many cases will be significantly better. It depends on what stage the transcription is at, though there's a helpful colour-scheme for each page which will let you know. Theknightwho (talk) 00:06, 31 May 2022 (UTC)

I suppose Gutenberg isn't too bad either, but mostly they and Wikisource have older, out-of-copyright works. We really need more current corpora. DCDuring (talk) 00:14, 31 May 2022 (UTC)

I would also like to add that Wikisource often features documents translated by the community. Vetting the origin of the sources seems reasonable to me. - Sarilho1 (talk) 12:04, 3 June 2022 (UTC)

Those should always be in the Translation namespace, so should be straightforward to spot. Theknightwho (talk) 12:07, 3 June 2022 (UTC)

For the record, I also agree that it is a bad idea to call community votes for individual words, and these should be promptly shut down as outside the purpose of that process. bd2412 T 02:54, 31 May 2022 (UTC)

This is nothing more than a unilateral attempt to stonewall implementation of the updated policy on online citations (badly-needed a decade ago) by throwing up unnecessary and time-consuming red tape. WordyAndNerdy (talk) 03:47, 1 June 2022 (UTC)

No? It's just moving it to a different zone. It's the same amount of red tape. Votes should be about website-wide issues, not individual words. The exact same discourse happening at the vote could have been resolved elsewhere. Vininn126 (talk) 12:30, 1 June 2022 (UTC)

I agree that votes are not a suitable forum for resolving ordinary RfV matters. What I meant is that Kiwima initiated these votes after being called out for unilaterally closing multiple RfV nominations as delete despite these words showing potential as being attestible through online sources. Kiwima drafted the policy proposal that lead to the badly-needed modification of CFI, but now seems to be insisting on a literal, unnecessarily bureaucratic implementation of "other online-only sources may also contribute towards attestation requirements if editors come to a consensus through a discussion lasting at least two weeks." Under this framework, instead of reaching a consensus on which online sources (e.g. Twitter, Reddit, Internet Archive) are acceptable for citation purposes, every single word attested through online sources must be individually litigated through a two-week vote or RfV discussion. It thus has the appearance of an attempt to forestall implementation of the updated policy on online sources by imposing an unnecessarily complicated and time-consuming process. Words cited by Usenet do not require "editors come to a consensus through a discussion lasting at least two weeks." The community simply agreed that Usenet was an acceptable source of citations, and that's been both policy and practice for over a decade. WordyAndNerdy (talk) 05:22, 3 June 2022 (UTC)

Ah, gotcha. I understand. Vininn126 (talk) 09:27, 3 June 2022 (UTC)

So that's why the discussion at dorcassing just ended abruptly as delete, despite there being a clear potential for finding citations. I remember finding that bizarre at the time, because many discussions stay open for months. Theknightwho (talk) 12:14, 3 June 2022 (UTC)

Unit-per-unit abbreviations

Hi all. I don't do much here, but I noticed a sort of oddity about inclusion of terms that I thought I'd bring up here in case anyone would be interested. There are entries for for certain abbreviations of unit/unit (usually distance/time that I've found, but there might be others) like cm/s (and cm/sec), km/hr (and km/h). We even have m/s², but not m/s/s or ft/s or ft/s². There's no J/s (that's a watt, which is not all that uncommon a way to find it), etc etc etc.

Anyway, should more terms be included? Should less fewer? These all feel pretty SOP to me, especially since there's a pretty large number of combinations that can be made. Just food for thought I guess. Deacon Vorbis (talk) 15:14, 29 May 2022 (UTC)

By the way, the closest previous discussion I could find was this, but that was more about combinations of prefixes and units. Deacon Vorbis (talk) 15:23, 29 May 2022 (UTC)

I added several of these earlier, but were deleted as a sum of parts. µg/day mAhg−1 µg/l You can see Talk:µg/l for an example discussion. Graeme Bartlett (talk) 06:00, 30 May 2022 (UTC)

French man, tan, san and similar neologisms

(Notifying PUC, Jberkel, Nicodene): A certain User:Frambosy has been adding and changing a lot of French entries involving gender-neutral pronoun/determiner neologisms. E.g. they created an entry for man and added it to the headword line for mon, and removed the "nonstandard" tag from iel. It's clear to me that man and similar neologisms don't belong in the headword line for mon, but I'd like to see what people think in general about these edits. There is a useful article here: [6] I gather that iel has some currency (the Wiktionary article has been around for three years now and there are numerous Internet articles on it) but I'm not so sure about man. The article I linked says:

The French possessive pronouns “mon” or “ma” are sometimes replaced by “mo” “maon” and “man” and the demonstrative pronouns “celui” and “celle” by “cellui” as well as “celleux” or “ceuzes”.

This implies that these terms have little or no currency. This reminds me of the English terms ze and hir, which Wiktionary marks as "rare" and "nonstandard" (see also xe, sie, co, ey). I have personally never encountered such terms in actual use (as opposed to mentions). Normal practice is rather to use they or to employ a pronoun-avoidance strategy, and I wouldn't be surprised to find that French is similar (French has no gender-neutral "they" but does have some gender-neutral forms such as notre, votre, leur). Benwing2 (talk) 20:52, 30 May 2022 (UTC)

@Benwing2 They are more "rare" than "iel" in terms of currency, but I have seen them in use once or twice. In general though, I'm honestly rather iffy about using the label "nonstandard" for neologisms, ex: labeling xe as nonstandard for example, who decides that? I'm sure that a lot of folks would label general neologisms found in English as "nonstandard", but what does that do for us? Sure, for languages like French, it's easier because there's the Académie Française, but if a growing number of speakers don't see it as the arbiter of language, should we? For example, the Académie considers spoiler (verb) nonstandard, but we don't have that label, nor does fr.wikt. So for me, I just wish there were some clarity on what should be labeled as "nonstandard" and what shouldn't. Maybe "(sometimes) proscribed" would be better here, but I'm unsure (see: frœur that I wrote last year based on the fr.wikt entry). AG202 (talk) 15:33, 31 May 2022 (UTC)

Isn't the Académie Française a bit of a notorious fossil? A more reasonable benchmark for the "abnormality" of these words would be (if it's true) that they don't appear in newspapers and would raise eyebrows if spoken on TV, etc. Equinox ◑ 15:37, 31 May 2022 (UTC)

Yes, exactly. We'd need to dig much deeper. AG202 (talk) 16:22, 31 May 2022 (UTC)

Hello, I am the one who added these different gender-neutral terms, I am myself a native French speaker and a non-binary person, I deeply understand your concern about these terms being rarely used because that is true, but the rarity of their use is in fact due to French morphology itself. Whereas in English possessive determiners agree with the one the thing belongs to, in French they agree with the thing that is belonged and as in French every words has its precise gender, therefore these determiners can be only used to refers to a non-binary person. Hence, even if someone was using these determiners systematically, they would not use them because they appears in very specific cases.

With regard to the mark “non-standard” and “rare”, I maybe wrongly thought that the marks “neologism” and “gender-neutral” was already enlightening on the nature of these words and their use. Moreover, I do think that the use of “non-standard” needs a definition of what can or cannot be considered as “standard”, and as one may know, the Académie Française whose in charge of this has currently no linguists in office, the institution has been created by the monarchy to perpetuate authoritatively the used of “good French” and has therefore only stated conservative positions that even sometimes went against French rules themselves (the use of only masculine forms over feminine for prestigious jobs, the masculine forms taking precedence over the feminine ones).

I would rather warn you that it is actually useless to search for their use in newspaper, or any sort of media because the use of “iel” is implicitly prohibited, and as a standard-setter they are actually quite conservative surrounding linguists questioning of our language and they usually follow the Académie Française unprofessional statements, as you may see by the impossibility of any orthographic reforms for over one centuries despite the potential consent of the Académie Française (the backlash of the 1990 Reforms, and the unfinished 1901 reforms)

In relation to the potential use of plural determiners, this use is actually illogical in French, unlike in English, because as we do not have a plural subject neutral pronouns, plural is only use to refer to several persons. Furthermore, the second-person plural is used for politeness in French (vouvoiement).

Finally I think they deserve their places in the Wiktionary because, despite their rare use, they are actually really logical and makes sense inside the French language, and can be useful for people interested in the gender-neutral French terms. Frambosy (talk) 21:14, 31 May 2022 (UTC)

As long as they're actually marked as rare. Nicodene (talk) 04:49, 1 June 2022 (UTC)

Invitation to join the Movement Strategy Forum

Hello everyone,

This is an invitation to all Movement Strategy participants to try out a new space for truly multilingual collaboration: https://forum.movement-strategy.org/

We are starting a community review period of two months. If the community feedback is positive, the Forum will launch in August 2022 before Wikimania. If not, we will follow the feedback received, changing the proposal or closing it.

https://meta.wikimedia.org/wiki/Movement_Strategy/Forum/Proposal

Looking forward to your first impressions!

Mervat (WMF) (talk) 10:01, 31 May 2022 (UTC)

first impression of "truly multilingual collaboration": 1. Click here and select your “Interface language”. 2. You need to be logged in to change your user preferences. 3. kthxbye. – Jberkel 16:38, 31 May 2022 (UTC)

Lots of process, lots of dotorgspeak. "Substance" best seen at Initiatives page. DCDuring (talk) 17:19, 31 May 2022 (UTC)