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.)

All done now, please have a look @Baloch007 !

Thanks @zeljkofilipin , all seems to be in order!

Shouldn't the logo be on the right side of the text, since Pashto is a right-to-left language?

Done.

I actually totally agree with that. The system needs a rethinking and reworking, so we should start a task for that instead (if there isn't one already?).

Ok from Langcom, patch submitted here.

Ok from Langcom, patch submitted here.

Ok from Langcom, patch submitted here.

Ok from Langcom, patch submitted here.

Ok from Langcom, patch submitted here.

Ok from Langcom, patch submitted here.

I am sceptical of this one, as Zapotec is a language group, not an individual language. I'm therefore inclined to reject this.

@Baloch007: As you can see, the change was merged, so it should start working some time after the 14th of August. Note that since the Saraiki Wikipedia is still in the Incubator, I'm not sure it will work properly in articles there or not. However, in the user interface it should be working (after that date), and when the Wikipedia is eventually created it will work in articles as well. But please let me know if you notice any problems.

Some suggestions for possible groupings:

It would be ideal if Special:MyLanguage for anonymous users would follow the browser settings of the user in my opinion. Not sure how easy that is, though.

I have posted about this in the Albanian Wikipedia village pump now, so unless there are objections I think the change can be made in one week. The other Albanian-language projects have such low activity that I don't see the point in even posting there, I think there the change can just be made.

Sure, will take a closer look when I get home from work today.