It's not a super-big deal, but I'm wondering:

• How are you going to identify that it's Wikipedia?
• Why is there a functionality difference between Wikipedia and other sites? Information about various namespaces can be useful on all sites.
• Can I read the research?

Immediate ideas about groups to divide:

• log messages
• language converter
• namespace messages (nstab, etc.)
• user rights (action-, right-)
• ignored messages

I'm not so enthusiastic about adding yet another code.

I support this. For just a bit more context, @zolfeqar brought it up in a conversation with me at the Central Asian WikiCon in Tashkent, and I suggested that he create this task.

There's another issue I've just noticed. It should very likely be fixed, and it is very easy to fix. The links point to https://en.wikipedia.org/wiki/Verifiability and https://en.wikipedia.org/wiki/en:neutral_point_of_view , but you probably want to point them to https://en.wikipedia.org/wiki/Wikipedia:Verifiability and https://en.wikipedia.org/wiki/Wikipedia:Neutral_point_of_view .

In T392624#10766525, @Isaac wrote:

Adding some context from an internal discussion to hopefully help whoever picks this up:

The issue is that the initial approach to language variants was to incorporate them into the URL path -- e.g., https://sr.wikipedia.org/wiki/<page-title> for default and https://sr.wikipedia.org/<lang-variant>/<page-title> for the variants. The code for measuring language variants then looks for that /<lang-variant>/ pattern in the URL path and extracts it. The other language editions seem to use a different approach, which is the same thing for the default variant but then https://tg.wikipedia.org/w/index.php?title=<page-title>&variant=<lang-variant> for the variants. Capturing those would require not just looking at the URL path but also URL params.

Update after the Central Asian WikiCon 2025, in which there was a large delegation of people who write in the Tajik Wikipedia.

The problem is valid, but I'm not sure that it's possible to do it at the moment because all these messages are in the mobile apps. Gender support is mostly easy in MediaWiki, but the mobile apps' code doesn't run on the MediaWiki platform. But maybe the apps developers will have an idea.

In T392437#10761429, @Jdforrester-WMF wrote:

This is a good spot, thank you.

Template:Citation needed and other related templates and modules appear under "Templates used in this preview", but the wikifunction Z18784, which is also used there, doesn't.

Templates are a core MediaWiki function. We aren't. It's very challenging to see how we should do this when Scribunto doesn't, for example. But worth considering.

Removing those links from existing wikitext is not an issue for Phabricator. This can probably be done with bots, if needed, and possibly repeatedly.

This should probably be closed as Declined. The jp, dk, and cz redirects should be kept, and I can think of at least one more redirecting "country -> language" code that should be added (I'll report it separately). I don't know how often jp, dk, and cz are used, but they are probably used at least occasionally, and they serve a clear purpose. I've actually seen people using "jp" when they meant "ja", because of lack of experience or because of a general mistake; I've never seen anyone using dk and cz, but they probably are used.

The same thing also happens in dag.wikipedia.org, which, to the best of my understanding, is Parsoid-default, but I might be wrong:

Is there anything left to do here?

The repository is on GitHub, but this is also part of our team's work, so it should be on Phab.

Some of these, like Sr and Skr do have namespaces in practice, but they are in the file for the fallback language.

Looks like it should be in Main, if it's something that a lot of end-users will see.

Is the remaining work about cleaning up the content? Or is there any work to do in language codes code in core (or extensions)?

In T387468#10674571, @stjn wrote:

As it says in I18n, it is a gargantuan non-specific mega tag so forgive me for not marking this task up with that. I’ll try not to forget in the future.

Sorry, I wasn't aware of this task. It is essentially a duplicate of T389491, which I reported. That is already supposed to be fixed, and if I'm not confused about scheduling, the fix is supposed to be deployed by the end of this week.

As @santhosh explained, we don't enable the tool by default in any language for any wiki.

There are a lot of RTL languages, not only Arabic and Hebrew. I see that Isa already uses the flask_babel library, so perhaps you can use babel's function for determining the text direction? I'm not directly experienced with it myself, but I found this: https://babel.pocoo.org/en/latest/api/core.html#babel.core.Locale.text_direction

In T388794#10634328, @Feeglgeef wrote:

The long name isn't allowed, you have to be exploiting a bug to have this seen.

Maybe this can be done, but why not just use zh? I understand that it's a macro language, but that's what we've always used in practice, and that's what (probably) the rest of the web does, so we can just avoid using cmn in wikitext.

No longer happens.

In T384395#10607538, @Bawolff wrote:

In addition to that patch, $wgCategoryCollation has to be changed for that wiki prior to running the maintenance script.

I reached out to a developer of one module, and showed a demo of how can a module be rewritten with the new Translatable module feature: https://meta.wikimedia.org/w/index.php?title=User_talk:CalendulaAsteraceae&oldid=28340327#Translatable_module

The patch is probably deployed, but I think that I still see the categories sorted with Ә towards the end and not in the beginning. Perhaps somebody needs to run a maintenance script to update the category pages? Just a guess.

In T386621#10595810, @Huji wrote:

For #4, I don't agree with Amire80's suggestion. What third example of such "technical names" exists that is neither a URL nor an email address?

The patch is testable at https://1120196--wikimedia-codex.netlify.app/style-guide/bidirectionality.html

In T384520#10591151, @DSmit-WMF wrote:

Maybe its unclear. I followed a bit of the same style as the existing 'wikilambda-mode-selector-button-label'.
"wikilambda-mode-selector-button-label": "Label for the mode selector button for accessibility, available for screen readers. Clicking on the button opens a menu to let the user change what \"mode\" of Object this is.\n\n{{doc-wikilambda}}",

In T386621#10562136, @Volker_E wrote:

Also, it would be helpful for many folks to orient, why the diacritics aren't needed?

In T384520#10584294, @gerritbot wrote:

Change #1113797 merged by jenkins-bot:

[mediawiki/extensions/WikiLambda@master] ModeSelector.vue: use MenuGroups from Codex now it exists

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

The problem seems to be the crh-latn and crh-cyrl now fall back to tr, but the default language of crh.wikipedia is crh, which falls back to crh-latn. I thought that in such a case, when something is not available in crh-latn, it would further fall back to tr, but apparently, it doesn't happen.

I can still reproduce it in the Arabic Wikipedia.

Was this discussed by the community of wiki editors who use these languages?

Awesome, thanks, I documented it.

Nice progress!

I tested it. Found a few issues, although only one was really important: T385194: fuzzy works in reverse after updating a message bundle, which is now fixed.