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?

In T285156#7316247, @Shushugah wrote:

[I]f someone wanted to add the "same" label value on a different language, should that trigger a validation error? I can imagine that would potentially disrupt bots who copy labels, but maybe that's not a bad thing if the goal is cleanup.

Yes, one of the goals is item cleanup, so such an error should be triggered.

In T285156#7314227, @Amire80 wrote:

So, mul is kind of the right code for that in general, but it's still a special case, and I'm wondering whether it's right to use it as usual aliases and labels. Can't it be a kind of an extra field in the data model, or a property, like "multilingual name" or "universal name"? Using just a language code for this sounds like a bit of a hack that can backfire.

I'd be interested to learn of a situation in which the addition of a label in this code with the intent described would cause things to backfire.

Are any of these actually useful?

This task is not intended to answer this question; since someone has found it useful to have access to this specific string in every language, using 'mul' is a more efficient way to address that.

Wikipedia disambiguation pages are handled very badly in general on Wikidata. It requires real structure and not a language code hack.

Can you elaborate of what's not "real" about the mul code with respect to disambiguation pages? While I'm sure there's much to improve for that category of item, that's not necessarily an argument against the introduction of this code for other purposes demonstrated.

This sounds like the right behavior. What if in some language the label was different? Asking seriously.

If the label in some other language is different from the "mul" one, then there's absolutely no harm for another language to add a different label. With respect to astronomical objects, on the typical multi-labeled item, only the Bengali label (and the Malayalam one, if it exists) is different from the rest, and thus would be preserved in the presence of a "mul" code; all others, being identical to that of the "mul" code, would be eliminated. (Again, if later one of those languages needs a different label from that of the 'mul' code, it is free to add that different label, and not the same one.)

As with the galaxy, it doesn't look wrong.

See the argument re: galaxies.

If the recent--judging from when label statistics started to note them--introductions of languages of Cameroon as languages for labels/descriptions/aliases is any indication, this request is likely for the same thing.

While I've undone edits on the last three of Nikki's examples (since those examples are frankly quite ridiculous), I otherwise agree with what is stated in that comment.

I also don't think disallowed codes should be excluded from a revert, in the interest of keeping behavior consistent with how deleted items/properties are dealt with.

In T284808#7224873, @Lucas_Werkmeister_WMDE wrote:

is this task specifically about the termbox user interface (either the old one or the new / mobile one), or is it supposed to prevent labels, descriptions and aliases in these language codes, everywhere (including in the API, Special:SetLabel, etc.)?

In T284808#7183772, @Lydia_Pintscher wrote:

Don't we already have this? I don't think we allow adding terms for simple for example? Or am I missing something?

Noting that no formal documentation of the behavior of concern in this task was yet provided by this task's objector, despite the assertion made that it exists:

The relevant piece of logic which this task considers was introduced in this commit, three years before Wikidata's launch and thus three years before the idea of pulling in information for an index page would have been conceived. We on the Bengali Wikisource, in the interest of modernizing the functionality of our site beyond the old days of direct {{header}} use and pre-Scribunto capabilities, are trying to embrace the benefits that Wikidata provides to the extent that it can support the metadata of index pages, and this necessarily extends from the slow discontinuation of certain index fields to the integration of their replacements in main namespace pages, in addition to the sometimes semi-automatic maintenance of some other namespaces. I can accept that such an attitude as we espouse may be foreign and uncomfortable to certain Wikisourcerors, but that doesn't mean that the software—which I feel the need to assert we wish to share with those Wikisourcerors—should continue to hold other communities back (or that the effort to defend what's being requested in this task is misplaced).

In T285610#7179748, @Xover wrote:

Is there any particular reason why you can't add a link to the mainspace page where the work is transcluded to one of the other index fields and use a dedicated field for the QID?

We are using the "wikidata-item" field as the dedicated field for the Qid. As (implied, maybe should have been expressed better?) in the sentence following that to which you replied, a link to where the work is transcluded would have been the use for the "title" field before, but that link has been migrated to a sitelink on a Wikidata item, which can be retrieved using Lua's mw.wikibase functionality, thus making it redundant to retain it in the index page.

In T285610#7179523, @Xover wrote:

that would require a better definition of what the actual problem with the current behaviour is

As part of an effort to increase integration of the Bengali Wikisource with Wikidata, we have begun migrating most information within index pages that can be migrated to Wikidata items. As a result, the only free-text field in ProofreadPage that is frequently non-empty before the pagelist is the "wikidata-item" field, holding the Qid of the work's item. The "wikidata-item" field is used directly within our implementations of "Module:Header template" and "MediaWiki:Proofreadpage index template" in retrieving the migrated information for display in the appropriate places. Turning that field into a link makes processing it, even if it's merely a matter of stripping the link syntax, just a bit more complicated than it needs to be. If the information above the pagelist field is already on the Wikidata item, then adding a link to any of the fields above the pagelist becomes redundant.

and some sketch of a hypothetical better solution.

The simple fix I propose is a direct solution to the problem and to the extent I am aware of would not adversely affect most other generated headers. (I'd be interested in seeing where an adverse effect might occur, if at all.)

In T285610#7179210, @Xover wrote:

putting a wikilink in the উইকিউপাত্ত আইটেম field should fix it.

Yes, I'm aware that throwing in an extra link is one way to sidestep the issue, but I wonder if the underlying assumption is worth hardcoding in the extension at all.

I have been semi-regularly migrating occasional additions of labels/descriptions/aliases in the languages codes noted in my original comment since that comment, in addition to an "no" to "nb" migration with @jhsoby's approval. The sooner these codes can be disallowed, the less work this will be for everyone.

In T282512#7076823, @Amire80 wrote:

OK, and mvf is OK, too. Is there such a task for mvf? I thought it's added already.

With Edge 90.0.818.49 on a 64-bit Windows system, I am able to get an item suggestion box to appear using the given steps.

I would like to assemble a JSON string with which to generate a lexeme using a single wbeditentity call.

In T277619#6922120, @FrancisTyers wrote:

Does this answer your question?

While I am not opposed to this language code request, @FrancisTyers, I do wonder what plans you have for this lexeme language code and the others you have requested, given that as yet you have not made any edits in the realm of lexicographical data on Wikidata in *any* language (as part of a general absence from Wikidata to speak of) and have not noted anyone who is planning to work with these languages.

In the lists in the linked JavaScript file for "bn" and "bpy", the entry for "system" is not present (unlike, say, in the lists for "af" and "ang"), and so by default pages are not rendered using the system font for non-logged-in users on bnwikisource, instead using the Siyam Rupali font by default since it is the first and only font in that list. This task was to rectify this situation so that system fonts would still render by default for non-logged-in users for such languages whose font.ini lists contain wildcards (the * symbol).

(@Mbch331 in your next set of patches for language codes, you should fix the typo in the name of the interface messages for the Rohingya code--both "en.json" and "qqq.json" use "rhog" instead of the correct "rohg".)

Some thoughts I had upon learning of this task (which may or may not be agreed with, but so it may go):

@Gehel would the measures taken in T272120 address this problem as well?

(never mind; was unaware of developments in T271342 since later in the day on the 29th)