Insightful question! I was not logged in at the time, and when I log in now, I see that a list can be imported from a text file without the erroneous capitalization bug if I am logged-in. 😮🤔 That's an interesting difference in behavior, and (IMO) still seems like a bug, as I would expect importing from a text file to work whenever the correct project is set (down in the lower right corner of the interface), not only when logged-in : other things, e.g. pulling all the redlinks off a page, work as expected (pull from the correct project, and don't add erroneous capitalization) whenever the correct project is set, without requiring that the user be logged-in.

I have tried to make the title a bit more descriptive, and added a link to the discussion where there is more information, https://en.wiktionary.org/wiki/Wiktionary:Grease_pit/2026/June#Linkage_of_Wiktionaries. This is, to my understanding, about the "文A" link at the top of each page, which on e.g. https://en.wiktionary.org/wiki/blazer displays "文A 32 languages" for most people but, for The.shahab on Mobile view on the English Wiktionary, only displays one language, Chinese. (I cannot personally reproduce the problem: on Desktop view I see "文A 32 languages" and on Mobile view, whether accessed from a computer or from an actual mobile device, I see "文A" and when I click on that I see a long list of suggested languages.)

On the English Wiktionary, we are experiencing MediaWiki:Edittools failing to display properly or be clickable, under the same conditions (it stopped working when editing a page, but works when previewing it), as described at https://en.wiktionary.org/wiki/Wiktionary:Grease_pit/2025/November#MediaWiki:Edittools. Curiously, English Wikipedia's Edittools appear to still be working.

This is still an annoying problem two years on...

Relatedly: the software already has the functionality to show what metadata is present in a file: it shows this information on the File: page. So as a minimum step, we could at least also show that information to the user during file upload (before they finalize the upload and the file and its metadata go live and public), T338288, so they could at least know what metadata their file had and decide whether to proceed with the upload or whether to back out and pursue a non-wiki-based means of removing the metadata, even if we don't add an in-wiki way for them to remove that metadata. (At present, the software simply shows a generic "EXIF metadata in this file may contain location or other personal data" message on all uploads, even if the upload contains no EXIF data or metadata.)

Thanks for looking into ways to address this!

@A_smart_kitten: Aha, no, the bug does not occur if I switch to Vector Legacy or Monobook. This explains why I only started encountering it within the last few months, because that's around when I switched to Vector 2022. Apologies for the redundant bug report, then.

I appreciate the explanation. I defer to the opener, @Ioaxxere, regarding whether this can be closed. (For context, the issue was noticed due to an en.Wiktionary discussion about whether to have "manual" redirects for long-s spellings, or whether the software can automatically "redirect" them; I will take this discussion as concluding that the software does not, and will not be made able to, automatically redirect them.

In fact, the situation is even more complex: if you search on en.Wiktionary.org for "uſ" or "aſs", you are taken to "US" and "ASS" respectively, not to "us"/"ass" or "Us"/"Ass" (even though all of those pages exist), but if you search for "ſharp" you are taken to "Sharp", not to "SHARP" or to "sharp" (even though both of those pages exist), i.e. in one case it is capitalizing the whole search string, but in another case (where the S is the first letter) it is not capitalizing the whole string, only the "S". And in a third case, there is a third behaviour: if you search for "Aſia" (or "aſia"), you are taken to neither "Asia" nor "asia": you are dumped onto the Search results page. (The same thing happens if you search for "CamelCaſe" or "camelcaſe".)

I've almost finished standardizing the Maya entries I mentioned, consolidating ~4 pairs of entries prior to your post. :-) Now I just consolidated 3 of the pairs you mention. The other 6 entries, for the individual characters, will probably be kept separate.

Whether it's bad to link pages on one wiki with one character to pages on another wiki with another character, depends on which characters would be treated as equivalent.

Late reply to "[do] words in different scripts" have issues like French/English wikis' apostrophes:

• Wikis use different codepoints (sometimes inconsistently) for palochkas; https://en.wiktionary.org/wiki/Wiktionary:Beer_parlour/2016/April#Palochka .
• Hebrew Wiktionary standardizes apostrophes (ר'), English standardizes geresh (ר׳).

Wiktionarians regularly fail to create redirects / interwiki links for this, so if Cognate ignores this until later, it doesn't make anything any worse than it is, IMO.