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

I should note that this has been happening for a while with a number of lexemes as well (such as L401588).

Per https://www.wikidata.org/w/index.php?title=Topic:W2fqtsb5r9css6vf&topic_showPostId=w2ftxgg8qbtux7h4#flow-post-w2ftxgg8qbtux7h4 this ticket can be safely closed for now.

This seems to be part of a general problem of language fallback not working when searching for grammatical features. When using Bengali as the interface language, for example, searching for "singu" does not return "singular" as one might expect; one has to search for "একবচন" to get the same item.

In the case of Chakma, there are cases of resources, such as those hosted by https://github.com/kalpataruboiChakma/, using both the Bengali script and the Chakma script, between which maintaining correspondences in lemmata/forms with different representations would be useful. Having ccp unqualified (in line with the script used on Incubator) and ccp-beng as language codes would thus not be controversial in my view.

In T272442#6765137, @Amire80 wrote:

The languages are probably legit, but is there anyone who actually knows them and plans to add lexemes in them?

In the interest of not having this stalled indefinitely, I've removed the request for syl-sylo from this ticket.

I'd like to shamelessly plug the middle thirty minutes of https://youtu.be/mzqX5iTfzb4 and the entirety of https://youtu.be/DFG5yEZLfC8 as some prior introductions to lexeme editing. I would be more than happy to work on the third (hopefully much more refined) version of such a thing.

I'd just like to note that the Suppress-Script value for Korean according to the official subtag registry is in fact Kore (meaning ko-Kore as a code is redundant in the eyes of a number of organizations).

@ObyEzeilo It is already possible to add Igbo monolingual text values; see for example https://www.wikidata.org/wiki/Q33578#P1705 where two "native label"s (a monolingual text type property) are given.

When opening this ePUB in Calibre's ebook editor, I notice that bold text appears to be rendered properly using fonts available on the system (in other words, the directive within the ebook's main.css to set all text in the body to FreeSerif does not seem to affect bold text), while all other text is rendered using FreeSerif as would otherwise be expected with such CSS. Not sure if this is an e-reader problem or a book problem.

In T258126#6678449, @Samwilson wrote:

Does the error in the first page come from https://bn.wikisource.org/s/ef1s ?

The new fonts do resolve this issue, save for the autogenerated first page in which conjuncts are still malformed.

@Loominade Any particular reason why P2125 (Revised Hepburn romanization) can't be added to forms as appropriate, in lieu of this language code?

In T267143#6632925, @Lydia_Pintscher wrote:

Are you looking at https://wmdeanalytics.wmflabs.org/WD_LanguagesLandscape/ or the test system at http://datakolektiv.org/app/WD_LanguagesLandscape ?

I was referring to the former of these; the link to the dataset folder provided on that page used to have label/description/alias stats going back to March for various languages in CSV files as late as last week. Now that page doesn't load (which I can understand being the case right now), but the same folder now only has statistics in those CSV files going back to 28 September.

Are the statistics from before 28 September still available? (They were there when I visited the charts last week, but the current files in the folder containing these figures seems to have lost them.)

I must agree with Bodhi here that having a code for sat-olck is still necessary as it is not guaranteed that Santali speakers outside of India will be able to read it. "Official" in India need not mean "official" in the other countries in which it is spoken, as a closer read of the article on the language should indicate. Besides, we already have separate language codes for a particular language and the scripts in which it is written, including the "default" (such as kk and kk-arab, kk-cyrl, kk-latn, or iu and ike-cans, ike-latn, and similarly for ks, ku, tg, and ug) so I don't see a problem with continuing this trend in the interest of preventing ambiguity.

I have recently migrated all uses of "bat-smg", "bh", "fiu-vro", "roa-rup", "zh-classical, "zh-min-nan", and "zh-yue" on labels, descriptions, and aliases to "sgs", "bho", "vro", "rup", "lzh", "nan", and "yue" respectively, so now would be a great time to at least disallow those language codes.

I have recently moved all uses of the code "zh-classical" for labels/aliases and descriptions to use "lzh" instead, if this helps anyone.

@Amire80 To my knowledge it is not mandated anywhere that all variants of the representation of a lexeme lemma/form must use Q number private use subtags, but rather such uses are possible if other existing subtags within BCP47 cannot adequately indicate the necessary differences. The indication of Japanese written in different scripts can already be done with the BCP47 script subtag, so (¡¡¡)within the scope of language codes(!!!) the items I mentioned which are currently being used for those indications are redundant. Also, as I noted above, the distinction between kyujitai and shinjitai does not lend itself to a non-private-use indicator within the set of possible "ja" language tags, so this task is not meant to discourage the use of those private use subtags in that case.

What time on September 1st was this? According to https://lists.wikimedia.org/pipermail/commons-l/2020-August/008161.html it appears the data is reloaded every Tuesday around 9am UTC; perhaps after two days your changes will then manifest in the query result.

This applies to the Mattermost mobile apps (for iOS and Android).

Now that the only patch tied to this ticket has been abandoned, and now that the Commons Query Service beta uses the sdc: prefix, can this ticket be closed?

In T261420#6416738, @AntiCompositeNumber wrote:

This script, called on page load, replaces every number in a thumbnail URL with that number truncated to an integer, which strips leading zeros. It was placed in MediaWiki:Common.js by Sushant salva in this edit. I'm not sure what problem it's trying to solve, so I can't really recommend a fix short of completely removing it.

(As a note, a patch for this task was already made at https://gerrit.wikimedia.org/r/616609, although it is likely that it did not show up here due to the absence of the line "Bug: T258982" in the patch description.)