Thank you, I have updated the description of this task with some information about subtags that would be useful to have with this language code.

It seems like you are exactly right about the 50 entity check limit being related to this issue - this lexeme is just shy of 50 entities total with 6 senses and 38 forms, and still shows constraint violations. https://www.wikidata.org/wiki/Lexeme:L1092922

For what it is worth, I have definitely noticed there is a limit in lexeme size of some kind where constraint violations no longer appear. I typically do not expect them to appear on Hindustani or Punjabi verbs. On the first sense of a lexeme adding a gloss quote usually results in a constraint violation, but if I add one now to this lexeme with over 50 senses no constraint violation is applied (the lexeme is https://www.wikidata.org/wiki/Lexeme:L33485 but see the screenshot since I do not want to actually leave this statement unreferenced.)

@Amire80 Makran is a region along the southern coast of Pakistani and Iranian Balochistan, and Makrani is the major dialect associated with that region and with Balochi as spoken across the gulf in Oman. See this source for example: https://dsal.uchicago.edu/dictionaries/collett/frontmatter.html Makrani is definitely a more widely recognized and used name for a variety of Balochi than the current autonym given to bcc.

As far as I can tell this is still not resolved—the language code was not available for monolingual text when I tried.

@Arian_Bozorg I could have made it more clear but this was not just for lexemes. I gave a specific example where it would be used for monolingual text.

Any thoughts on this? @Lydia_Pintscher @jhsoby

I have also updated the autonym since finding some additional information for this.

This can now be closed as the code was made available today via the interface translations.

Dingal is a Rajasthani language which lacks a language code of its own https://www.wikidata.org/wiki/Q5278158

Done

Done

I have added items for a number of scholalry works written in Brahui, such as https://www.wikidata.org/wiki/Q113302350

Done

Done

Done

In T328890#8664641, @Fjjulien wrote:

I was excited to see this feature request being moved into a "task". However, nothing happened with it for the last three weeks. Is this normal?

Just adding a note here that we now have a property for Pakistan Sign Language lexemea on Wikidata https://www.wikidata.org/wiki/Property:P11652

Just adding a note here that we now have a property for Torwali lexemes in Wikidata — https://www.wikidata.org/wiki/Property:P11301

It would be great if the links simply showed gloss(es) in the language of the lemma if available. As a matter of practicality, I am not in the habit of glossing senses in languages other than the language of the lexeme—each gloss takes a certain amount of time to add, and if I want to minimize the amount of time I am spending writing glosses this is optimal. I don't need to see every gloss in my interface language and don't expect to.

This would be useful for quoting mis- or poorly transcribed transcriptions of text, as well as the titles of works which consist of invented words.

And here is the Gerritt patch ready for review: https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/859080

OK the message and the bottom of the new item page is the same but is getting resolved differently - I figured out the issue by process of elimination looking at the other translations and the new lexeme page source code - the license name variable is hard coded for Special:NewLexeme and substituted in English, something else is happening on Special:NewLexeme. I think if I allow it to insert the English string it will resolve, it was possible to translate the whole thing on the old page

The brackets are in the correct direction - TranslateWiki will actually not let you publish translations without brackets in the correct direction. The markup also resolves in the Translatewiki interface. Using FSI/PDI that way just forces the characters to render that way. They do not behave like quotation marks which can make things confusing.

The message(s) on the new item page are different as far as I can tell.

Yes, it is strange - it seems specific to this string, in this version of Special:NewLexeme, in this locale. I initially added that commented line when the Special:NewLexeme (old) page and Special:NewLexemeAlpha page were both online, where the comment would be hidden on the first. (The comment saying something along the lines of, if you are seeing this message, it is because there is an error preventing this wikitext and substitutions from resolving.)

Actually that can be achieved with TemplateStyles once the font is added ^

You could try sux-x-QID as I don't think that format is limited to mis. The advantage of using a QID is that it may be localised; what would be nice is to render a label based on the QID

I think that's exactly what it is actually. There are problems with all of the Indic ULS keyboards I have tried. I was not able to replicate this

Also, I am not sure if this is within the scope of this ticket, but enabling the "swash" feature where it is used is a good idea. Maybe this is something I have to work out where the right CSS files are, this is explained here https://developer.mozilla.org/en-US/docs/Web/CSS/font-variant-alternates

@KartikMistry The GitHub issue above has been resolved, along with fixes for rendering several ligatures, in the latest version v1.002. I would say the font is ready to be added

I will point out that the terms and conditions section does not actually render as intended in every locale. For pnb it shows raw wiki markup and the links do not resolve.

This occurs for me on mobile Chromium for Android - none of the drop downs for anything show options or allow selecting something.

An example of what I mean may be seen here in the usage example statement: https://wikidata.org/wiki/Lexeme:L722046

As a rule, the direction should be set to "ltr" or "rtl" as appropriate if known for the language, and "auto" if the language is unknown.

This is likely the same issue as T321441 , where a solution has been posted. I did not spot this in checking to see if a ticket existed

@Nikki was able to help identify that this problem is caused by a textarea with inset: -9999px auto -9999px auto set as an HTML style attribute.

Changing the labels on items also causes this problem.