I hate that "feature" in Wikifunctions. Overwriting people's clipboard content without warning is rude. I want to be able to select text without losing what I have in the clipboard, and that includes IDs, because I can do things like drag them into another field or middle-click paste in Linux.

The description of this ticket seems inaccurate. Languages have never been added to Names.php for Wikibase, as far as I know. Languages are added to $wmgExtraLanguageNames for Wikidata and Commons because it's not acceptable to add them to Names.php (for some unknown reason). It would be much simpler for Wikidata if things could be added to Names.php instead of needing a custom configuration, see T273627 (including the comments).

In T374354#10129654, @gerritbot wrote:

Change #1071602 had a related patch set uploaded (by Bodhisattwa; author: Bodhisattwa):

[mediawiki/extensions/WikibaseLexeme@master] Add lexeme language code txo-toto for Toto language

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

This was not done correctly. Lexeme language codes need to be added to LocalNamesEn.php in the CLDR extension, so that MediaWiki has a language name for them (the ones in the WikibaseLexeme extension are not used anywhere except Special:NewLexeme). That will automatically make them available for lexemes.

CLDR's data is in kok.xml (see https://github.com/unicode-org/cldr/blob/main/common/main/kok.xml), it doesn't have a gom.xml file.

The message wikibase-lexeme-lexicographical-data is in the WikibaseLexeme extension now.

The message is in the WikibaseLexeme extension now.

based on https://global-search.toolforge.org/?q=.*&regex=1&namespaces=8&title=Lang%2F%5Ba-m%5D.* and https://global-search.toolforge.org/?q=.*&regex=1&namespaces=8&title=Lang%2F%5Bn-z%5D.*

It seems it broke at some point between the 27th of September (https://web.archive.org/web/20240927015640/https://translatewiki.net/wiki/Project:Privacy_policy) and the 5th of October (https://web.archive.org/web/20241005214803/http://translatewiki.net/wiki/Category:Translatewiki.net).

In T320889#9403141, @hoo wrote:

As part of T341409 this has been (mostly) done. WikibaseLexeme, for backwards compatibility, still supports the following language codes which we don't support for monolingual text values:

bat-smg
be-x-old
de-formal
es-formal
fiu-vro
hu-formal
nl-informal
roa-rup
simple
zh-classical
zh-min-nan
zh-yue

This is the same problem as T215051, T262269 and T350746.

This is the same problem as T215051, T262269 and T266940.

This is the same problem as T262269, T266940 and T350746.

https://query.wikidata.org/#select%20*%20%7B%20wd:L1071911-S1%20?p%20?v%20%7D has data that was deleted in March last year.

In T375352#10178989, @Bugreporter wrote:

Currently all Wikidata properties are usable in Commons Metadata (though some are missing UI support).

I also can't reproduce this. Following the steps in Edge 128.0.2739.79 gives me the menu as expected.

{{#dir:...}} incorrectly returns "ltr" for 75% of the language codes in Template:Dir. It's a long way from being a replacement for the template.

In T372702#10071526, @Nikki wrote:

I have centralauth_Token cookies on both computers where it's happened, both have expiry times in August next year.

It happens while the browser is still running for me. When it happened yesterday, I was editing Wikidata and when I tried to save my edits, it gave me an error saying that it had failed because I was no longer logged in.

I've also put the autonyms that are in CLDR in P68546

Columns are the language code, the autonym from CLDR, and the English name from the CLDR extension.

I've put a list of language codes currently available for monolingual text (and lexemes) which aren't in language-data at P68526. I added the code I used to generate it as a comment, too, if anyone wants to generate a newer version at some point.

Generated by running the following in the browser console on the page for a Wikidata item:

I found this ticket because the Merge gadget is not tagging all of its edits, e.g. here the edit which created the redirect does not have the "merge.js" tag.

That line was removed a long time ago in https://gerrit.wikimedia.org/r/plugins/gitiles/wikidata/query/gui/+/45149ba72f50f94805aea995d5aa287828510f88, so this is probably fixed now?

In T371990#10050012, @Bugreporter wrote:

This is because L1234 does not have lemma in English or any languages in fallback chain. You can enter an item QID without English label or description (random example: Q29323432), and label and descriptions will not display either.

In T372702#10071410, @Lydia_Pintscher wrote:

Yeah the same people/account gets logged out several times over the span of a few days.

@Nikki and other affected people: do they have a centralauth_Token cookie?

The columns are the language code used for the Incubator pages, the total number of pages, and the language name in the BCP47 registry, if the code exists there.

In T304392#10057019, @Ainali wrote:

Note that it needs flexibility, as in some cases, one would like to be able to link to a specific form. For example Sv-anden (wild duck).ogg should link to L251549#F2

In T285617#8489381, @Nikki wrote:

It also tries to submit the edit when pressing enter while the button to add a lemma is focused.

In T334563#10054830, @Alhadis wrote:

FYI, I was the one who removed the (ostensibly) redundant en-gb label @Nikki spoke of. I find this complication to be emblematic of a more broader issue—the need to distinguish regional variants from an ultimately "neutral" variant (which in English's case, is unfairly assumed to mean en-us). It would be nice if regional variations were defined explicitly, perhaps laid out like this:

In T139010#10053678, @Winston_Sung wrote:

This is really confusing to use cdo-Hani .

• Mindong is not even writing in mixed-Han like "新音楽時報" ("楽" + "時", "報").
• The "not simplifyable" statement is false. I've found some examples using Mindong Simplified Han writing, for example, "侬" ("儂").

In T365302#9810654, @Bugreporter wrote:

The following code snippet is copied from https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1032542/14/includes/parser/CoreParserFunctions.php:

	if ( strlen( $code ) >= 4 ) {
			// RTL scripts per https://docs.google.com/spreadsheets/d/1Y90M0Ie3MUJ6UVCRDOypOtijlMDLNNyyLk36T6iMu0o/edit
			$rtlScripts =
				'Arab|Hebr|Thaa|Syrc|Nkoo|Samr|Mand|Avst|Cprt|Armi|Phli|Prti|Khar|Lydi|' .
				'Sarb|Orkh|Phnx|Merc|Mero|Mani|Mend|Narb|Nbat|Palm|Phlp|Hatr|Hung|Adlm|' .
				'Rohg|Sogo|Sogd|Elym|Chrs|Yezi|Ougr|Gara|Sidt';
			if ( preg_match( "/^(.+-|)({$rtlScripts})(-.+|)$/i", $code ) === 1 ) {
				return 'rtl';
			}
		}
		// Strip country codes
		if ( strlen( $code ) >= 5 ) {
			$code = preg_replace( '/-\w{2}($|-)/', '', $code );
		}

Note inside the language class the language code is $this->mCode

Here's the results for "desc" on the same item with the interface language set to en:

A few days ago someone removed the en-gb label (which was identical to the en label) from P973 (described at URL).

In T356161#9497847, @Lucas_Werkmeister_WMDE wrote:

I doubt the same situation is possible on Wikidata, since we disallow moving items, properties or lexemes, and the moving seems to be a crucial part of how the history was split here.

Isn't this the same as T193001?

This happens in a variety of situations, e.g. with datatypes and alternate property paths, as reported in January at https://www.wikidata.org/wiki/Wikidata:Report_a_technical_problem/WDQS_and_Search#bug_with_autocompletion_of_datatypes

Is this the same as T317530?

https://wikiba.se/ontology-1.0.owl also includes <!ENTITY cc "http://creativecommons.org/ns#">

Also, the search results have been awful for a long time when the UI is set to British English (T334563). mul will probably have the same issues.

In T370293#9990985, @Epidosis wrote:

Maybe the best solution would be adding a parameter to the constraint allowing the user to specify if, for that specific property, "mul" should be taken into account or not. This would be the most flexible solution IMHO.

Should we generally decrease the importance of the number of labels for ranking or do something special for mul?

Not sure if this is the same problem or not, but searching for "CJK UNIFIED IDEOGRAPH-4E0D" or "U+4E0D" in the search at the top of the page or when adding a statement doesn't find https://www.wikidata.org/wiki/Q3594922

It seems the badges disappeared between 2023-08-31 and 2023-09-09:
https://web.archive.org/web/20230827105318/https://de.wikipedia.org/wiki/Englische_Sprache and https://web.archive.org/web/20230831130105/https://de.wikipedia.org/wiki/Uranus_(Planet) have badges for alswiki,
https://web.archive.org/web/20230909134644/https://de.wikipedia.org/wiki/Englische_Sprache and https://web.archive.org/web/20231017183307/https://de.wikipedia.org/wiki/Uranus_(Planet) don't.

The query service is also dropping some characters like the left-to-right mark (U+200E), which caused me to accidentally create statements that look like duplicates when using QuickStatements, e.g. https://www.wikidata.org/w/index.php?oldid=2211924924#P1705

In T367644#9895757, @Aklapper wrote:

Allowing local wiki to use free web fonts where they need, maybe site wide (which may is covered by ULS

AFAIU this exists, see https://www.mediawiki.org/wiki/Universal_Language_Selector/WebFonts

I fixed the lemmas and representations on forms with a bot as soon as the codes were available on Wikidata (e.g. https://www.wikidata.org/wiki/Special:Diff/2162481928) and there don't seem to be any left according to https://w.wiki/Afkm.

Sarai wanted to sort the list alphabetically by the language name, originally.
The dev team asks is sorting by language code would be good enough? It would have the advantage that it is only one order for all UI languages.

In T358572#9586340, @Arian_Bozorg wrote:

Thanks for picking up on that Nikki!

Let's check to see if this is solved once this patch is merged: T353729

I had another look and noticed that the glosses table doesn't use the full width available to it.

Another place where this hook could be used: Appending https://www.wikidata.org/wiki/Property:P2559 to the descriptions of properties, since T97566/T140131 still haven't been fixed.

I generally test in private tabs, so English, because it always uses English for people who aren't logged in. Which language are you using?

I can't find a ticket for it, but this is a problem with Minerva in general, it doesn't have a button for changing the interface language in other wikis either.

https://gerrit.wikimedia.org/g/mediawiki/extensions/MobileFrontend/+/cfea6265a59dd44c63dc7fdaea994a594a133ecc/src/mobile.languages.structured/util.js#194 currently has:

return a.autonym.toLocaleLowerCase() < b.autonym.toLocaleLowerCase() ? -1 : 1;

This just happened to me with https://www.wikidata.org/w/index.php?diff=2166801293.

This is still a problem, https://query.wikidata.org/#select%20*%20%7B%20wd:L1144506-F7%20?p%20?v%20%7D returns data that was deleted in August last year - https://www.wikidata.org/wiki/Lexeme:L1144506

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.