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:

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.