Ideally we'd allow all ISO 639-3 codes (T289776) so I think the easiest thing to do is to rename wya to "Wyandot-Wendat" (or maybe "Huron-Wyandot", the name used in Glottolog) to distinguish it from the new wyn code, and add both new codes.

To let people who aren't logged in change the language, set $wgULSAnonCanChangeLanguage to true.
To enable language detection, set $wgULSLanguageDetection to true.

In T342937#9364420, @Jdforrester-WMF wrote:

There's no real use-case for adding Wikidata links for 99% of pages on Wikifunctions. The language change control from ULS isn't supported and doesn't work correctly, but we can't configure it unfortunately; you should use the real language change control that we provide instead.

In T342937#9341062, @Jdforrester-WMF wrote:

I've temporarily hidden #p-lang entirely via https://www.wikifunctions.org/wiki/MediaWiki:Common.css but we should fix this properly.

In T341409#9337791, @Lucas_Werkmeister_WMDE wrote:

The only one I can’t make any sense of is dlc, which MediaWiki says is “Dalecarlian”, yet Dalecarlian language doesn’t mention a dlc language code. Apparently the cldr extension (but not the actual CLDR) took it from Ethnologue in 2008.

Searching my chat history I found that I had actually reproduced it before, but I couldn't find a ticket so I assume I never got round to making one.

In T290657#9219270, @Aklapper wrote:

I guess Debian needs to ship an updated package which the Wikimedia servers which run Debian would use: https://tracker.debian.org/pkg/unicode-cldr-core

This was fixed a few months ago by adding the names to LocalNamesEn.php in the CLDR extension - https://github.com/wikimedia/mediawiki-extensions-cldr/commit/35fb17407f3af8bc12f3d3e8c6a62579785cce44

Some of these have since been fixed, but it still affects non-runr, and others I hadn't mentioned like sat-latn. Making the names completely consistent will also mean changing mis, which currently shows "unsupported language" in most places, but "other" on Special:NewLexeme.

I was going to move my repos for Wikimedia-related things from GitHub to gitlab.wikimedia.org, but disabling issues has made it completely unsuitable for me (and community repos in general, I guess, given how many people use sites like GitHub for issue tracking).

I don't think we should use a non-standard order for the parts. We've been trying to replace non-standard language codes with ones which follow BCP 47, so it doesn't make sense to introduce new non-standard ones.

Yep, now it's invisible again - T277559

Shouldn't the acceptance criteria be that text and links in selected table cells have enough contrast?

In T102417#8067232, @Mike_Peel wrote:

I think this is no longer needed, since it's now 'multilingual sites' rather than other sites, which is a big improvement.

In T314476#9231057, @Winston_Sung wrote:

Wikidata:

• https://www.wikidata.org/wiki/User:Mr._Ibrahem/Language_statistics_for_items
• https://www.wikidata.org/wiki/Special:Search/haslabel:ks-arab
• https://www.wikidata.org/wiki/Special:Search/hasdescription:ks-arab
• https://www.wikidata.org/wiki/Special:Search/haslabel:ks-deva
• https://www.wikidata.org/wiki/Special:Search/hasdescription:ks-deva

Regardless of what the "perfect" solution should be, can it please at least be changed from P218 to P305?

It seems to be listing results for both the interface language (de) and the fallback language (en). If you search for "russ" it finds both "Russisch" and "Russian":

Interwiki links to akwiki are behaving strangely now. On https://meta.wikimedia.org/wiki/Meta:Administrators, it's displayed with the other links, but shows "ak:Wikipedia:Administrators" where the language name normally is. On https://incubator.wikimedia.org/wiki/Wp/sli/Wikipeedia:Administratoren, it's not recognised as an interwiki link and is displayed as an inline link at the end of the page instead.

In T117845#9200743, @gerritbot wrote:

Change 421793 merged by jenkins-bot:

[mediawiki/extensions/cldr@master] Rename language codes sr-ec and sr-el to sr-cyrl and sr-latn

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

Something like this might work:

.wikibase-snakview-body {
	display: grid;
	grid-template-columns: auto 1fr;
}

In T347311#9198612, @M2k_dewiki wrote:

With the workaround, for me it is not possible to call QuickStatements from the PetScan results, in order to create missing wikidata objects for unconnected articles or to connect articles to already existing objects.

In T341409#9018965, @thiemowmde wrote:

I might get this wrong. But as I understand the proposal it would make the currently established processes of how languages on wikidata.org are managed, requested, and confirmed (briefly described in T312845) obsolete.

In T333765#9144332, @jhsoby wrote:

In T333765#9137835, @Nikki wrote:

Autonyms come from Names.php

… or from InitialiseSettings.php's wmgExtraLanguageNames; since the problem with ak missing – as far as I can tell – is specific only to Wikidata, I would suggest adding it there.

This is supposedly resolved, but it's undocumented and when I run the function, it doesn't add a portlet section anywhere that I can find.

In T333765#9138177, @agray wrote:

In terms of sitelinks, there are currently 325 akwiki sitelinks on Wikidata (https://w.wiki/7N$e) - all to internal pages (templates, categories, etc). I am guessing these can be more straightforwardly deleted if desired.

It's because ak was removed from MediaWiki - T333765

It's no longer possible to change ak values in Wikidata and Commons in any way because MediaWiki says the language code is invalid.

I think this would be a bad idea.

In T230833#7800700, @Lydia_Pintscher wrote:

We discussed this today in the bug triage hour and decided that we need to look at this again once T284882 is solved.

It should be working now - https://www.wikidata.org/w/index.php?diff=1965684317

Ahh, I see. :) It would be great for that tool to finally have lexeme support! I would be a lot more interested in trying it out then.

If constraints are not working on lexemes now, that seems like a big regression because they definitely used to, see e.g. T223372 which has a screenshot of a constraint violation being shown on a lexeme page.

I'm usually using Vivaldi but I've seen it happen at some point in every browser I've tried so far.

In T344577#9121959, @Lydia_Pintscher wrote:

I just checked and I can not reproduce this anymore. I have hidden categories enabled. Can you check again?

QLever is able to handle certain queries like these, e.g. https://qlever.cs.uni-freiburg.de/wikidata/nF1iKM (one of the queries mentioned in the description) gave me the results in under a second, whereas the same query in Blazegraph times out.

I realise this ticket is already closed (I only just noticed it) but please bear in mind when making any decisions about how to split the data that introducing mul will hopefully result in a huge change to these numbers (at least for labels/aliases).

In T135871#8055585, @Manuel wrote:

Hi @Nikki, I have removed the following case that originally came from T267131:

• Make any change to the language currently set as the interface language, no save needed.
• The heading updates immediately, no longer applying language fallback

My reason is that the interface language is likely factored in by design. The problematic part as I see it is that language fallback doesn't come back after one cancels the action (should be fully covered by case B). Please let me know in case you have any objections.

Could you provide an example of a template? As someone who isn't an English Wikipedia editor, I don't know what exactly "in a citation template" would be referring to. What currently happens when you try to use ruo?

Because that's what https://www.wikidata.org/wiki/Special:Preferences#mw-prefsection-gadgets tells people to do.

This doesn't seem to actually be fixed, I'm still getting a list instead of a table sometimes, e.g. https://w.wiki/6Lr8 in a browser window about 1036px wide:

In T303677#9035100, @tfmorris wrote:

I'm surprised that this hasn't received any attention in 15 months. As an update to @Nikki 's numbers there are now on the order of 2.5 BILLION of these bot generated descriptions. The top 5 alone represent over 2 billion triples. That's a huge waste of resources!

ahmad already explained how they're written/read on more than one occasion:

In T11436#8616757, @Al12si wrote:

This is not a feature request; this is an outright bug. It’s 2023 already and all mainstream browsers have implemented writing-mode: tb, but when we try to use it we’re greeted with “Invalid or unsupported value for property writing-mode” and our CSS doesn’t even save. This is not an acceptable state of things.

In T152875#8130755, @ahmad wrote:

Can't the code flip the images by a graphic transformation at the time of rendering, instead of duplicating the glyphs set in the extensions resources? I haven't checked again recently, but I remember the glyphs were vector graphic files, correct?

Also, instead of preceding each token with a dash, it would be much more practical, and less prone to errors on part of users of the extension, if an optional single token was to be placed at the beginning of the sequence to indicate the direction.
Ideally, this should be accompanied by a settable global default at the level of the extension's instance. This way, a right-to-left mediawiki instance will default to rendering hieroglyphs RTL unless otherwise indicated, and vice versa for a LTR wiki instance.

I've noticed this too because it looks horrible in German, e.g.
On https://www.wikifunctions.org/view/de/Z12 if you expand the first part that says "texts":

• "Art Der Datenobjekte Auflisten" (should be "Art der Datenobjekte auflisten")
• "Objekte Auflisten" (should be "Objekte auflisten")

On https://www.wikifunctions.org/view/de/Z112:

• "Eingaben Eingeben" (should be "Eingaben eingeben")

In T325607#8898528, @SCherukuwada wrote:

@Soda Yeah Navboxes would indeed have helped.

Tell me if this makes sense re: categories. If a page isn't in any category or is in a category but isn't otherwise linked to, how would the crawler know how to find the category? As far as I can tell the mechanism for listing all categories (Special:Categories) is also in the special namespace, which is uncrawlable.

The mobile site is so limited that it's not really usable anyway so my recommendation would be to disable it on Wikidata and focus on improving the desktop site instead (see T330820)

Here's a more complete stylesheet/script I've been working on based on my original prototype (with screenshots): https://www.wikidata.org/wiki/User:Nikki/NarrowUI

I've added it for the page "Wikidata:Main Page". If that doesn't work, you'll have to tell me what the right JSON key is. :)

I made a pull request for sh-cyrl and sh-latn way back in December: https://github.com/wikimedia/language-data/pull/271

Another place which appears to depend on wmgExtraLanguageNames:

Some examples:

I'm aware it's not unique to DiscussionTools (I also made T340266 at the same time), but I made this ticket specifically for the links created by DiscussionTools because it's a separate extension.

In T321852#8713041, @Lydia_Pintscher wrote:

Good to go from my side as well. Let's do it.
I fear the data migration needs to be done by the community via a bot.

It has since been updated in CLDR:
https://github.com/wikimedia/mediawiki-extensions-cldr/commit/3eb9037934444946c65d5f6e29db0c409f995f54#diff-b146c2d7954635aec3488511efc4923b7d1af6452dec5c51a2a30434fcd30e0dL347