If the user doesn't like the auto-description then the user can fix the two or three wikidata statements used to generate the description. This will fix the description in all languages so this is what we should be encouraging. Fixing the English description will just fix the English description.

@daniel I agree Sitelinks mostly works. as designed. We just get strange corner cases where a wikipedia has two articles about the same topic in two different languages/dialects and they can't add sitelinks for both. I would expect there to be a way to do these sitelinks.

There are FOUR separate use cases which need to be treated differently

Do we need a separate phabricator item for "multilingual text language tag should support multiple scripts for one language (separate language tag for each script)"?

This is very important for the "monolingual text" datatype. We do not enter text in a language. We always enter text in a script. For properties where we make the datatype "monolingual text" it is because we want to know the data in that language. Where there are alternative versions in multiple scripts then it is a requirement that we note which script has been used for the value entered. This is not negotiable. the "language" tag for a "Monolingual text" value is meaningless if it doesn't specify which script version of the language that value is in. In many cases it will be more important to specify the script than the language (since there well may be multiple languages using the same script version).

In T54564#1278605, @Jane023 wrote:

..... My question still stands - why would you want to merge two distinct Wikidata items to each other, if one was a person and the other is a duo?

Conceptually descriptions and usage notes are different things. The link between them is that users need to see both of these in pop-down lists on the user interface to help the users pick which to pick.

In T94404#1186925, @daniel wrote:

@thiemowmde The number of incoming links would be the best indicator, since it directly correlates with the probability of the user wanting to link to the entity. But calculating it is too expensive, even on edit; Cirrus search has a similar problem, and a solution (I don't remember, ask Nik). Once we move term lookup to Elastic, we can use it.