@Ladsgroup both Epìdosis and I were using QuickStatements (he version 3.0 and I version 2.0); your complaint about tools not respecting maxlag should be directed at @Arcstur in the former case and @Magnus in the latter case.

I don't think it's true yet that an entire lexeme can be created in one go if form and sense IDs have to be calculated when preparing a QuickStatements batch. "Item for this sense" statements, as the property name suggests, go on senses; they do not go on lexemes as the command examples given show. There are lots of other statements that can go on senses (images, semantic genders, external IDs) and forms (pronunciation, morphological context, external IDs) as well, and what I fear will happen with the current setup is that someone decides to write up a batch thinking, naturally, that LAST refers to the last entity (whether lexeme, form, or sense) created, or that they will simply omit all statements on forms/senses due to an unwillingness to calculate form/sense IDs.

Just hopping in to say that if you want to create lexemes with senses at the same time as forms (and thus reduce the number of edits in your creations) the twofivesixlex Python library exists for that: https://gitlab.wikimedia.org/toolforge-repos/twofivesixlex/ ("overview.md"'s section on "Creating lexemes" should help)

There is now (and has been for some time) a module on the Bengali Wiktionary that produces a (sub)entry on a Wiktionary page based on the content of a lexeme: current pages where this module has been used are listed at https://bn.wiktionary.org/wiki/বিষয়শ্রেণী:উইকিউপাত্ত_আভিধানিক_উপাত্ত_থেকে_আমদানিকৃত

This problem persists with lexemes as well; https://www.wikidata.org/wiki/Lexeme:L1531124 and https://www.wikidata.org/wiki/Lexeme:L9913 still appeared in query results for a long time. (I had to undelete and redelete them in order to get the deletions to register, but I don't think this workaround is particularly scalable.)

The header template on bnwikisource has been updated to provide this information now, and it now surfaces in the Wikisource app.

A similar problem (the same one?) was reported as https://github.com/maxlath/wikibase-cli/issues/192 .

And a traceback from Mishramilan at 18:01 UTC:

It seems like resolving T284808 is a necessary precondition for the situation presented in this task.

This appears to have been the case since June 8th at 7 UTC; what could have gone wrong then?

I note that this same phenomenon is occurring on the Bengali Wiktionary and the Bengali Wikibooks, but not on the Bengali Wikisource.

Related: T271776

In T345177#10402869, @Arian_Bozorg wrote:

It isn't very clear where the constraint violations aren't appearing

In T378097#10350052, @EBernhardson wrote:

I see that sense's can also have statements. Should those be similarly indexed?

Yes, this would address the second example in the task description.

I believe T344170 would be helpful here.

In addition to the above issues, any text that uses the U+200C ZERO WIDTH NON-JOINER is returned by the Query Service with that character removed, resulting in the lemmata and form representations of Persian compounds (such as for the lexeme "آفتاب‌گیر"—notice the character sequence "ب‌گ" in the middle of the word) being returned as single units ("آفتابگیر"—notice how the "ب" and "گ" in the middle are joined) where this was not the intended display. Because the positions of the ZWNJs are not predictable, obtaining the correct textual representation requires retrieving the lexeme from Wikidata separately and pulling it from there, which is inefficient.

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: