The code which generates the description lives at https://phabricator.wikimedia.org/diffusion/EWLC/browse/master/src/Hooks.php$137, and the functions getStatementCount() and getFormCount() live in https://phabricator.wikimedia.org/diffusion/EWLC/browse/master/src/LexemeResult.php$87 .

'universal' != 'English' or 'English-centric' (which the UVI and its components are); I cannot support giving this as a task (even if it is modified to use the suggested template) without expanding its scope to multiple languages further removed from English (by which I mean those that are either 1) not Indo-European or 2) not primarily spoken on the European continent).

Regardless of whether this proposal is modified to use the suggested template, I think this is better as a simple on-wiki bot request rather than as a full-fledged summer project.

Turkish already exists as Z1237 and Azerbaijani as Z1597. Languages are some of the "special kinds of objects" thus locked down.

What's strange is that https://translatewiki.net/wiki/MediaWiki:Wikilambda-about-widget-language-count-button/bn never had spaces between the curly brackets.

I am here just to second the aforementioned concerns and would support a format that merely displays any gloss, rather than give up, if neither my interface language nor any in its fallback chain are present on a sense.

As there are both form identifiers and sense identifiers, having wikidata:identifiers for forms and senses would be useful, and as there are around 12.1 million forms and around 300,000 senses, I am willing to supplement Nikki's offer by removing 6.7 million more unnecessary triples from a variety of places.

This may be related to UniversalLanguageSelector (whose Hindi Transliteration input method was used to type the word in question).

This task asked for lexeme support as well and T320889 hasn't happened yet.

cf. the approved T282512 and the as-yet-unapproved T286239

T209282 and T284882 are the reasons that nso must be specified manually; it is not about any lack of support within WikibaseLexeme or elsewhere.

Here's an example of this phenomenon on iOS 12.5:

(Perhaps being tired of my complaints raised in another forum led to the dearth of detail in the initial task description, but...)

In T309317#7960803, @ori wrote:

• What is broken?

When I click "edit source" on that page, and I type "Z10004" into the dropdown next to "value" for the field whose label is "catena" and save, the field's type changes from "Reference^(String)" to "Reference^(Reference)", rather than to "Reference^(Catena)" as I would expect.

• Is there any indication it is specific to Beta cluster? (i.e. does the same workflow work as expected in a dev environment?)

The type creation interface on notwikilambda.toolforge.org is broken, since on adding fields to a type in the CreateZObject page there I am not prompted to name these fields nor shown the ID (Z12345K2 etc.) that they would have, so I have no clue as to this point.

tools-sgebastion-10.tools.eqiad1.wikimedia.cloud:/home/mahir256/2fa-reset-request.txt should contain a link to this task.

I will fully accept the first two bullet points you mentioned, and to some extent the third bullet point, but believe the fourth is somewhat limited and must take issue with the fifth.

In T307820#7911140, @ori wrote:

Cool, sounds like you've thought about this quite a lot -- can you expand on that / do you have this written down somewhere?

As the person behind Ninai and Udiron, I must agree with Cory :-) . Besides, there are some facilities I believe are needed for traversing the item and lexeme RDF graph, which do not yet exist, that will make multilingual text generation more feasible in the long run.

Yes, w.wiki/bKf (for all train lines emanating from St Pancras) and w.wiki/4xyY (for the path from Narvik to Singapore) use that service.

In T304208#7790431, @Aklapper wrote:

In T304208#7790354, @Mahir256 wrote:

As this is not the first task involving the use of @Pathoschild's script, you may wish to complain to that user that people find those scripts useful enough to consider them a default staple for others.

@Mahir256: That makes no sense at all.

Let me rephrase, then: please tell that user "Would you mind re-hosting all of your scripts on Meta, rather than on wmflabs, and adjust your documentation to follow suit, given that people find those scripts so extremely useful that they enable them for everyone, even with the apparently mistaken assumption that wmflabs is a production server?"

As this is not the first task involving the use of @Pathoschild's script, you may wish to complain to that user that people find those scripts useful enough to consider them a default staple for others.

This may be substituted with the same font hosted on wmflabs's FontCDN:

The two references to fonts.googleapis.com use fonts which exist on wmflabs's FontCDN and can thus be substituted accordingly:

Is this better merged into T298633 as a general graphical-programming-language support task?

I'd like to suggest a change to infer the spelling variants from P‌220 or P3‌05 per T284882.

In T285610#7541238, @Tpt wrote:

I am a bit scared of linking to the first page if the current page is not in the toc.

I must agree with Xover's comment regarding the provision of a next link on a main page. While attempting to provide such a link using JavaScript and the mw.Api may be possible, I do not think that it is necessarily the most efficient use of resources when loading a Wikisource page, given that each time a page is loaded the table of contents portion of an index needs to be rendered again (meaning after ProofreadPage does so once) to determine which link to add. (The alternative would be to add the next link manually to the page, which does not fully comport with the underlying motivation behind this task.)

Now that we are on wmf.9, I see that for this index, with "data": "toc" set for the table of contents ("Remarks"), and without using the trick mentioned in T285610#7267935 on that index, the second chapter still does not link to the first chapter or vice versa. Is there something we need to refresh on our end for the effects of this patch to be visible?

We have an as-yet unused "Query:" namespace ; perhaps it could be opened for storing queries longer than 2000 characters? (A redirection mechanism such that a visit to any page in that namespace takes you to query.wikidata.org might be useful, and there ought to be a system, similar to what is done with CSS pages, that ensures that a query is syntactically correct before it can be saved to that namespace.)

If we're rejecting tlh as a monolingual text code (and not as a lexeme language code), would someone like to do the honors and purge the Lexeme: namespace of Klingon lexemes?

Per https://www.mediawiki.org/wiki/Wikibase/Indexing/RDF_Dump_Format#Truthy_statements, "Truthy statement predicates have prefix wdt: with the property name (e.g. wdt:P2)" and "[I]f there is a preferred statement for property P2, then only preferred statements for P2 will be considered truthy. Otherwise, all normal-rank statements for P2 are considered truthy." As your screenshot indicates, "visual artist" is a preferred occupation statement (the little shaded up arrow on the left) and the other occupations are normal-rank statements (the little shaded dot between the two blank arrows).

In T294159#7467990, @Lucas_Werkmeister_WMDE wrote:

Would any of the early adopter projects be willing to have Lexeme access enabled while the Lua interface isn’t stable yet[...]?

I'd be interested in such a thing for bnwiktionary.

I would like to propose bn.wiktionary as a test project for this, with an intended use case being the construction and display of inflection templates for nouns and verbs.

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.

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.

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

The following is a comment made in another forum regarding this ticket by User:Nikki, who has allowed me to repost it here after some copy-editing in good faith:

In T285156#7378750, @Ash_Crow wrote:

Why? In absence of the proposed mul language code, having the same label duplicated in all languages that use it is the expected behaviour.

@Amire80 @jhsoby What do you say?