@Lucas_Werkmeister_WMDE and I read through everything and spent some more time thinking this through. Thank you everyone for providing all the input, especially @Nikki. That really helped.
One thing to still clarify or the discussion (which I also wasn't aware of): The language fallback chains do not have to make up a tidy tree. It can (and does in places) have cycles and a language can have several fallback languages. For example avk falls back to fr, es, ru; mdf and myv fall back to one another (before both fall back to ru).

Based on @Nikki's analysis it makes a lot of sense to us to only do mul for now and see how that goes. Then the remaining question is about the exact fallbacks we want. The options we see right now are:

• the fallback to mul happens after the fallback to en at the very end of all fallback chains (example chain de-at -> de -> en -> mul)
• the fallback to mul happens before the implicit fallback to en but after any explicit fallback (even explicit fallback to en from e.g en-gb) (example: en-gb -> en -> mul or de-at -> de -> mul -> en)

The question boils down to if for non-English languages, a fallback to e.g. Amphispiza bilineata is preferable to “Black-throated Sparrow” or not.

Do you have thoughts on these options?

I think "the fallback to mul happens before the implicit fallback to en but after any explicit fallback" is preferrable (since I think Amphispiza bilineata is preferable to “Black-throated Sparrow”).

Just one more point (probably already expressed): I think that

• when "mul" has a certain X label, it should be technically impossible to add the same X label to any other language code
• when "mul" has a certain X label and another language code, e.g. "de", has a Y label, it should be technically impossible to add the alias X to "de" (= in general, if a language code has a label different from "mul" label, the "mul" label should be automatically considered an alias for this language)
• when a certain label X gets added to "mul", all identical X labels should be removed from other language codes

@Epidosis What should happen when mul is in Cyrillic ? You seem to assume mul-latn.

I'm somewhat worried that all these deletions will lead to the people adding "Giovanni"@it to "John"@en and we are back to where we were years ago.

If mul is in Cyrillic (e.g. it will probably be in https://www.wikidata.org/wiki/Q29652874), it will happen as follows in my opinion:

• "mul" label = Афанасий
• if a language code has no label, it will default to "Афанасий"
• if a language code has a transliterated label (e.g. "en" label = Afanasy), for this language code one of the aliases is by default "Афанасий"

This seems fine to me.

Regarding deletions: of course there might be some misuses, but in fact I think that deleting a lot of duplicate data in labels (and aliases, in my opinion) is the reason for which "mul" is most useful, so in my opinion it is worth trying.

@Epidosis for that sample, it seems clear-cut, but for Q191118 one could imagine Cyrillic "т" as "mul" label.

Interesting question about the fall-back chain from Lydia. Maybe we should give more thought about the language code applicable to taxon names. Its code could then be part of the fall-back chain and the value displayed when available. There is some discussion on Wikidata what the code should be. Let's assume it's "la-x-taxon". We could have languages fall back to that and it could easily be read.

Personally, I rather see a feature that prevents re-additions for items with specific types (P31=..) before we experiment with deletions. Maybe some sort of protection setting could work too. Sample: if there is mul-latn, there shouldn't be en,it,es, .. This would work for name items, but also disambiguation items, possible others.

In a case like https://www.wikidata.org/wiki/Q191118, I tend to think a general label is not applicable (each language has its name for "tonne"); having "mul-lat" and "mul-cyr", I would set "t" as "mul-lat" alias and "т" as "mul-cyr" alias; having only "mul", I would set both "t" and "т" as "mul" aliases. Anyway, it is reasonable to start applying "mul" (or similar) with specific types of items (I tried to list them above; starting with some of them, as disambiguations, could work well).

The idea of an apposite code for Latin name of taxa seems very interesting to me.

In T285156#7322423, @Epidosis wrote:

There are at least 3 categories of items which strongly need this:

1. persons (https://www.wikidata.org/wiki/Special:Search/haswbstatement:P31=Q5, as of now 9.2M): in most cases the same label and the same aliases are repeated in different languages (e.g. in wikidata.org/w/index.php?title=Q19667413&action=history I can count 6 same-label additions: fr, nl, sl, ca, ast, sq; many other items are similar)
   • in the case of people, "mul-<script>" is required: names are the same only considering languages with the same alphabet, I'm mostly thinking about Latin alphabet
   • in some cases there could be the following problem: one Latin-script language may prefer a form (e.g. "Philip L. Brown"), another Latin-language script another form (e.g. "Philip Larry Brown" or "Philip Brown"); while the group of labels and aliases is the same for all same-script languages, which is the label and which is the alias may vary from language to language; of course, this problem occurs only when there is more than one form of the name, but in many cases this doesn't happen
2. given names and family names (https://w.wiki/3zWT, which counts Q202444 and Q101352 including subclasses, as of now 590k): in all cases the same label are repeated in different same-script languages (e.g. https://www.wikidata.org/wiki/Q21448867)
3. scientific articles (https://www.wikidata.org/wiki/Special:Search/haswbstatement:P31=Q13442814, as of now 37.3M): in most cases the same label is repeated in different languages (e.g. https://www.wikidata.org/wiki/Q27860672)
   • in some cases there could be articles with parallel titles in different languages (e.g. https://www.wikidata.org/wiki/Q59238742)

Considering also

4. asteroids (https://www.wikidata.org/wiki/Special:Search/haswbstatement:P31=Q3863, as of now 247k)
5. galaxies (https://www.wikidata.org/wiki/Special:Search/haswbstatement:P31=Q318, as of now 2.1M)
6. taxa (https://www.wikidata.org/wiki/Special:Search/haswbstatement:P31=Q16521, as of now 3.1M)

and still leaving out disambiguation pages (https://www.wikidata.org/wiki/Special:Search/haswbstatement:P31=Q4167410, as of now 1.3M), we obtain 52.6M items, out of 94.9M items, and probably the count could be further increased.

Ideally, as I noted, "mul" and "mul-<script>" should allow exceptions in some way, but their necessity is very clear. I would suggest at least medium priority.

@Epidosis

The problem with "mul" is that we couldn't easily have the software test if there should be ru/uk label (as for "John"), but no la/fr/en label on items.

In other words, when we have "mul-latn" and name item, we could avoid adding la/fr/en, but not ru/uk.

I don't mind testing it with disambiguation pages, but in general, I still think T139912 is worthwhile. Maybe asteroids could do (not too many).

https://www.wikidata.org/wiki/Q59238742 might be tricky. @en and @mul-latn would have the same label (unless we decide that such items should only have @it and @en)

In any case, I like the idea that all these items would get much lighter.

OTH, name items only need one label and transliterations could go into statements. So the setting would be "mul" + name > no other labels.

@Esc3300 please refrain from editing the task description while the discussion is ongoing. It is inappropriate to masquerade your personal opinion as the hard-won consensus that we are trying to achieve here.

@LucasWerkmeister Can you outline which of the deleted points you consider problematic? Lydia generally wants to summary in task descriptions to be up-to date. If you just remove stuff, we are missing out on information.

@Lucas_Werkmeister_WMDE that should have been. I removed Mahir256 as they seem to be doing nonsensical edits to subscribers.

Odd that some of known issues shouldn't be stated in the task description.

@Lucas_Werkmeister_WMDE that should have been. I removed Mahir256 as they seem to be doing nonsensical edits to subscribers.

The presence of the user I am removing—not just here, but in any other discussion forum really—has made @Nikki (and others, both actually and potentially) sufficiently uncomfortable directly opining here and in those other fora that others like myself relay their opinions here for them. Unless that user wishes to impugn the credibility or emotional strength of Nikki and those other individuals, I contend that my actions in this regard are entirely sensical.

Changes for task description are:

Can you explain the reminder of your deletions? Above what you deleted from the description.

@Esc3300 For clarification: Lucas and I spent a lot of time yesterday on getting everything to a point where we believe it is sensible and the remaining questions are clarified. It'd be good to concentrate the discussion on those remaining points now because otherwise we can not move this forward. As there is a strong desire from several editors to get this done I want to push this to the point where we can actually pick it up.

please refrain from editing the task description while the discussion is ongoing. It is inappropriate to masquerade your personal opinion as the hard-won consensus that we are trying to achieve here.

This message (especially the latter part) is enough of a reason to undo the changes made to the ticket since Nikki's comments were added, irrespective of what opinions I may hold of any of it (which should not be assumed as was done in the diff that stains this task). The sea lion I am removing from this ticket is also free to impugn Lucas's or Lydia's credibility or emotional strength as well.

In T285156#7388183, @Lydia_Pintscher wrote:

@Esc3300 For clarification: Lucas and I spent a lot of time yesterday on getting everything to a point where we believe it is sensible and the remaining questions are clarified. It'd be good to concentrate the discussion on those remaining points now

Ok. What's the proposal for the various points in how it may backfire? And finally which script do you want to start with?

In T285156#7388192, @Mahir256 wrote:

please refrain from editing the task description while the discussion is ongoing. It is inappropriate to masquerade your personal opinion as the hard-won consensus that we are trying to achieve here.

This message (especially the latter part) is enough of a reason

@Mahir Can you explain which parts the later part covers? If not, please refrain from making such comments in phabricator or elsewhere.

For those who would like a clarification,

please refrain from editing the task description while the discussion is ongoing.

this is the former part of Lucas's message

It is inappropriate to masquerade your personal opinion as the hard-won consensus that we are trying to achieve here.

and this is the latter part.

(More on the "sea lion" term.)

Apparently there is a disagreement between Lucas and his manager about description editing.

Can you at least explain which parts you consider my personal opinion and which ones are not supported by a consensus (ideally with a link to the relevant discussion)?

There is no disagreement.
We are spending a lot of time discussing things that currently don't move this forward and do not help get to a meaningful consensus. So one final try. We need input on the final remaining discussion points as I laid out in T285156#7384455. Let's please concentrate on those now so that we can then update the task description once we heard everyone.

If this is the only open point, can you summarize how the open points mentioned in the task description had been addressed ?

Sure.

• Could this solution somehow backfire? -> several answers in this thread that we will weigh and see if they warrant any action
• What are all the mul-<script> codes that we should start with? -> none, we are just going with mul for now as I said in my comment
• How exactly should be the fallback chain for these mul codes? -> no fallback within the mul codes because we only have one. fallback to and from other languages is in my remaining questions

In T285156#7388535, @Lydia_Pintscher wrote:

• Could this solution somehow backfire? -> several answers in this thread that we will weigh and see if they warrant any action

Can you propose something?

Step #3 mentions constraints. What will they be?

I understand that you are keen to get this done, but compared other new language codes, we are still moving quite fast. I think we all don't want this to go into a dead end.

Thank you all for your input on this! We will put this in development right after the no deploy weeks. Special thanks go to @Nikki and @Mahir256, for driving and enlightening this issue, and to @Amire80 and @Epidosis, for your valuable input!

@Esc3300: You also gave helpful input and we appreciate the effort! At the same time, your style of engagement and your continued disagreement with the direction that we took in the deliberation seems to have ultimately led to some demotivating arguments and loops in the discussion. I am sad to see that all of this resulted in a bad climate and a frustrating experience for some of the discussion's participants. It is essential for Lydia and me that - especially for hard decisions like these - we still maintain an open and welcoming climate for all people involved, as well as a worthwhile and productive discussion. This is why we would like to ask you for your help in fostering more open and welcoming discussions that respect our process in the future.