This is probably covered by T63958

They don't contain a dot or comma, but while testing something, I also found that "91-04 bc" and "0091-04 bc" turn into "1 April 91 BCE" (and for some reason "0091-04-00 bc" turns into "31 March 91 BCE").

This is probably the same as T167263.

These are available for lexemes and monolingual text now.

These are available for lexemes and monolingual text on Wikidata now, but don't seem to be available on wikibase.cloud wikis yet. I don't know when/how often those are updated.

This is available now. I've fixed the lexemes but the monolingual text statements still need updating.

This is available now.

These are available now.

This is available for monolingual text and lexemes now.

These are available for monolingual text and lexemes now.

These are available for monolingual text and lexemes now.

These are available for monolingual text and lexemes now.

This is available now. I've fixed the lexemes but there might still be monolingual text statements that need updating.

These are available now.

These are available now.

These are available now.

These are available now.

These are available now.

These are available now.

These are available now.

This is available now.

This is available now. I've fixed the lexemes but the monolingual text statements still need updating.

This is available for monolingual text and lexemes now. I've fixed the lexemes but there might still be monolingual text statements that need updating.

This is available now. I've fixed the lexemes but there might still be monolingual text statements that need updating.

These are available now and I've fixed the ones I could find.

In T231755#9768211, @Bugreporter wrote:

Note: hts is not currently supported in MediaWiki core, translatewiki or language-data/ULS.

The underlying assumption here is that only MediaWiki uses these formal/informal variants.

In T362305#9707870, @TomT0m wrote:

The IETF code seems to be (see https://www.wikidata.org/wiki/Q18795#P305 ) "ko-KR", with capital KR.

I think the following changes in rebuild.php (GitHub) would make the CLDR extension use CLDR's mni-mtei for MediaWiki's mni:

In T231755#9766262, @Lucas_Werkmeister_WMDE wrote:

Hm, two complications.

1. How do we get the LocalNames translations into upstream CLDR?

In https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2023/Translation/Translatable_language_names last year, I suggested adding all the languages and then importing the translations from CLDR so people don't have to retranslate them. If we did that, it could also update translations when they change in CLDR (maybe only if the name in Translatewiki matches the previous CLDR name, if we want to avoid overwriting names).

I'm not Amir but I generally agree with https://ux.stackexchange.com/questions/119565/mixed-alignment-ltr-and-rtl-in-language-selection-list - direction is not the same as alignment, the direction should be set correctly, but switching between alignments in a list doesn't look right and is hard to use.

It does do fallback, but normal MediaWiki pages (i.e. not the Wikibase interface on entity pages) use the user's language fallback chain (which is affected by the languages in their Babel box), unlike entity pages which only use the default fallback chain for the interface language.

In T259183#9695299, @gerritbot wrote:

Change #1017480 had a related patch set uploaded (by Nikki; author: Nikki):

[mediawiki/extensions/Wikibase@master] Set a minimum width for values in statements

https://gerrit.wikimedia.org/r/1017480

The big problem I have with user scripts is loading dependencies and the incompatibility between gadgets and user scripts more generally.

I think that patch should fix 2, 3, 5, 6, 7, 9 and 10 from the description.

I can't use the mouse to select text to delete or replace, for instance, if it is toward the end of the gloss, because as soon as I click the mouse it resets to the first characters of the gloss.

Are you still able to reproduce this? It seems to be working fine for me in Firefox now.

The example I gave isn't reproducible now, but the underlying problem is still there, e.g. https://www.wikidata.org/wiki/Lexeme:L406433?uselang=fr loads with "jersiais" which is replaced with "Jèrriais" after loading.

118 and 119 are custom namespaces (they don't have the same meaning on all wikis and not all wikis with draft namespaces use 118 and 119 for them), so this is probably the same as T52655.

In T358862#9590551, @Amire80 wrote:

It's correct according to the current algorithm. It's just not very useful ;)

The likely reason for that is that "de" appears in names of many languages in many languages, for example "amazighe de l’Atlas central" in French. See https://www.unicode.org/cldr/charts/44/by_type/locale_display_names.languages__a-d_.html#346e71a8ed4de6f8

aew and twl are also prefixes matching existing language tags.

I saw the references to a keyboard shortcut dialog in the source code years ago, couldn't figure out how to make it show up (despite looking at the code to try to work out how it's triggered) and concluded it had never worked. This is literally the first time I've seen anyone else mention it.

Does this still happen? I haven't been able to reproduce it.

In T359822#9624135, @Dbrant wrote:

the original non-BCP-47 language code (lowercase zh-hans)

In T355427#9472831, @Lucas_Werkmeister_WMDE wrote:

Automatically shortening https://en.wikipedia.org/wiki/Victor_Hugo to “en:Victor Hugo” is an interesting idea that I don’t remember being proposed before… though it has the problem that en: is ambiguous between English Wikipedia, English Wikibooks, English Wikisource, etc. (which isn’t a problem for commons:).