In T218155#5509071, @Ankry wrote:

Later changing the internal field names (to Hindi, as they are in the initial configuration) may be a pain, however. If it is ever intended.

In T218155#5508368, @jayantanth wrote:

Thanks @Ankry for your comments. Presently there are 28,307 Page: and 40+ associate Index files. So are you advice to do this again start from scratch ?
I can do this all configuration if I have interface admin access.

In T190981#5474787, @WMDE-leszek wrote:

Adding a value using the language code works, but the language code is not shown, just a code. This probably requires a change outside of Wikibase software.

In T174349#5482483, @Trizek-WMF wrote:

Spotted here: "The proposed solution is quite reasonable."

In T189427#5458461, @eugrus wrote:

Despite this patch I am still getting the "peo" is not a known language code error on Wikidata.

Ok from LangCom.

Ok from LangCom.

@Mbch331 As far as I can tell from the Wikipedia article Taíno never had a written language before it went extinct, so I'm not sure what would be put into these monolingual properties? And the code "car" is apparently for the modern-day Carib language, which doesn't go by Kalinago?

Ok from LangCom for monolingual. We could add it for labels + descriptions as well, shouldn't be a problem.

Ok from LangCom.

Ok from LangCom.

(not trying to steal any honor here)

The problem this bug is about has been solved (more than a year ago), so closing. :-)

Whee, go @Reedy! I can try to import the Neapolitan contents from Wikisource.org at the hackathon tomorrow unless someone else wants to give it a go.

In T138332#2623867, @Lydia_Pintscher wrote:

It is a blocking issue in so far that an item can only link to one page on a given wiki. If several languages are covered on one wiki then we also usually have the case that we have two pages for one concept on that wiki that would both need to be linked in the same item.

I definitely see a difference in the background color of the selected tab and the rest of the tabs. If I tilt my screen just right, however, the difference disappears.

All done, the logos are uploaded to the category SVG Wikimedia chapters logos from Finland. Please let me know if you spot any mistakes, or if the files should have a different naming scheme – I have move rights on Commons, so I can easily do that.

I have these covered if you don't mind, Susanna. ;-) I'm at the Oslo Freedom Forum with @Yupik right now.

Might I suggest that setlang should be changed so it doesn't actually change the language instantly but rather open a dialogue where the user can accept or deny that change?

Also submitted a pull request in wikimedia/language-data on GitHub.

While testing for this I noticed that when I click "edit" and then "cancel" twice on the sitelinks for any item with existing sitelinks (like Q42), all language codes displayed turn into aa, and all links point to aa.wikibooks.org (even though the links are in the Wikipedia section). No idea if it's related or not though.

It does not work in the Index namespace either. I remember checking the "underlying structure" of a page using &action=raw a few months back, like late last year, and it was working then, but not now.

Pite and Lule Sami already work – the autocomplete for typing the language name doesn't work, but that's a different issue. If you type in the language code, they work.

Sorry, I thought I had closed this. It turned out to be a browser issue with Chrome – IIRC, the thing I needed to do to fix this (on my machine) was to enable "GPU rasterization" on chrome://flags, and everything went back to normal. So it wasn't actually a Wikimedia-specific problem at all.

Probably because of the gadget "maintenance-menu" having it as a
dependency. I'm on mobile so it's difficult to link it, but you can see it
on [[MediaWiki:Gadgets-definition]].

In T202794#4872014, @Liuxinyu970226 wrote:

@jhsoby:

• nah Nahuatl

I strongly oppose you to call it as "valid language", because per SIL, the nah is a Collective code for a group of Nahuatl languages.

But this Herald rule doesn't affect Norwegian users. It only affects what Jeblad subscribes to. If he doesn't want to be subscribed to tasks about <nowiki>, then he knows what and how to change it. I still fail to see why this would be an issue for you.

I don't see why this would be a problem for anyone other than Jeblad…? Why is this an issue for you, Liuxinyu?

Oh ok, that's good!

Looking at the en.json file, I think it would be necessary to flatten it. So instead of a nested structure like you have, the strings should all be at the same level.

The edit right is assigned to the group "Users", which means that nothing has really changed (since only that group could read and edit before this change). All the patch did in reality, then, was to put a strike through internal in Special:SiteMatrix …

What does "close" mean in this context? I was able to make an edit there just now.

In T210752#4805284, @Ruthven wrote:

@jhsoby That's the translation. It's up to you to separate the words and use lowercase, or keep the AwkwardCamelCase

Special:IndexPages   --> Speciàle:Paggene Ennece
Special:PagesWithoutScans   --> Speciàle:PaggeneSenzaScan  (e.g. can be Paggene senza scan)
Special:ProofreadIndexOai   --> Speciàle:EnneceLeggiutoOai
Special:ProofreadIndexOaiSchema   --> Speciàle:EnneceLeggiutoSistemaOai

The index and page namespaces are defined in the Proofread Page extension, for which I just submitted a patch above. In addition to this, you can localize the names of the following special pages:

Hmm, I just checked in Firefox and the problem is not there. That led me to believe it was a browser issue, and it turned out it had something to do with GPU rasterization in Chrome. Enabling that solved the issue. So it is apparently not a Wikimedia problem after all.

I just came across another example of this: The Wikinews logo. Here as well it is more noticeable in small sizes, see e.g. where the logo is used on this page. It seems like there is a sort of green glow around the sides that shouldn't be there.

In T128060#4718290, @Esanders wrote:

Whenever we talk about spaces what we actually mean is wordbreaks, however many languages (e.g. Chinese) don't have obvious word breaks (you could guess if you had a really good dictionary..), so any change here would definitely make things worse on those wikis.

Nope, all good. Thanks for the reminder!

*Eastern Arabic.

Well yes, I know what "test" means. But what the hell is a squasher in this context?

Thanks @Jonas et al. Community consensus is already there, see https://wikisource.org/wiki/Wikisource:Scriptorium#Enable_arbitrary_Wikidata_access_for_oldwikisource .

This may be the case for more languages in that list. Do you have time to look into that and amend this task to reflect that if necessary?

List of languages with valid language codes and at least some content in oldwikisource:

Since the translate extension was enabled (T201814), which includes this feature by default, I believe this can be closed. I don't think setting the default page language to mul is possible without changing the wiki language itself, and that would probably have really bad side-effects, so it's probably better to keep it at English. But please feel free to reopen (and possibly change the task description/title) if I'm wrong.

One thing that needs to be figured out is how to add languages to language-data where we don't know the native name of the language. Right now, the design of language-data makes that a requirement to be added, but there are many languages that could (and should) be supported in e.g. Wikidata and mul.Wikisource where we don't have that, making it impossible to add them properly.

Looked some more into it, and it seems that the list of languages you can choose corresponds directly to the list of languages in Names.php.

Well, changing page language is part of the Translate extension, so I think someone from Language-Team could tell us that. I'm not sure if changing it in language-data is enough – I added a few languages there six months ago, but those are still not available to choose as page languages, so there must be something more to do. Maybe @Nikerabbit or @Amire80 could shed some light on the matter?

Also made a pull request in wikimedia/language-data on GitHub.

Since there is no development on this, I have committed a change 454700 to revert the autonym change, as outlined as option 3 by @tstarling in T174160#3798644.

Note that I'm not sure if there are any more changes needed to make this happen. I just copied the settings that were made in the patch for T159316. Maybe @Ladsgroup can shed some light on that.

(Sorry about my confusion up there, when marking this as a duplicate I got an error message which led me to think action wasn't performed, while it turned out it actually was.)