Wikimedia Forum

← Discussion pages Wikimedia Forums Archives →
QA icon clr.svg

The Wikimedia Forum is a central place for questions, announcements and other discussions about the Wikimedia Foundation and its projects. (For discussion about the Meta wiki, see Meta:Babel.)
This is not the place to make technical queries regarding the MediaWiki software; please ask such questions at the MediaWiki support desk; technical questions about Wikimedia wikis, however, can be placed on Tech page.

You can reply to a topic by clicking the "[edit]" link beside that section, or you can start a new discussion.
Filing cabinet icon.svg
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} and sections whose most recent comment is older than 30 days.

Proposal: That WMF ask Google to stop indexing certain bot-generated articlesEdit

  • Problem: Google is picking up on of ceb.wikipedia geography articles that have been created by bot. The articles are more than 95% spot-on, but when they are wrong they are very wrong. The incorrect information may even be in the title. One example is that the bot produced three articles for the same island in the same location, but each article claimed the island was in a different county. This would not be a problem to the English-speaking world if it wasn't that the titles of the articles are in English, either completely or in part. Because of this, the bot generated information gets fed into Google results for searches made in English. Due to the thousands of bot generated articles it is not practical for humans to completely curate the ceb.wikipedia articles anytime soon. As many of the bot generated articles have some value, it does not seem reasonable to demand that ceb.wikipedia change its standards and delete all the articles en masse.
Proposal: Instead, the WMF should ask Google to stop indexing all ceb.wikipedia geography articles in English speaking lands such as North America and Canada that depict local geographies like counties, cities, towns, buildings, islands, reefs, etc. Articles on states, provinces, and countries may still be indexed. There should be an opt-in whitelist mechanism for certain important locations like Manhattan or Oahu, but ceb.wikipedia must indicate that they have curated these articles with a human reviewer.
Additionally, Google needs to not index all wikipedia clones of the blacklisted ceb.wikipedia geography articles. The WMF should ask Google to do this.--Epiphyllumlover (talk) 19:30, 12 June 2020 (UTC)
Now that this is in the right venue, I'll comment on its merits. First, this doesn't require an explicit request to Google, and could be done by noindexing the pages. This could be accomplished by a configuration change, followed by an edit to ceb:Template:paghimo ni bot. Second, why is it the duty of the Wikimedia Foundation to care about individual wikis failing to properly curate their content? * Pppery * it has begun 20:02, 12 June 2020 (UTC)
Noindexing sounds like a great idea. In addition, the WMF should coordinate with Google so that all Wiki-clones of noidexed bot generated clones do not show up on Google either. Google needs to develop software that tracks which wikipedia pages are noindexed, and then use it as a screen against clones. The WMF should suggest this. As for the duty question, the WMF doesn't have a duty to get information right but rather an incentive if they want people to take the encyclopedia seriously. An analogy could be made with the National Weather Service offices--before releasing their data they coordinate with other regional offices to make sure that their forecasts do not contradict each other. There is nothing inherently wrong with, say, a rural area near the border of two National Weather Service districts having wildly different forecasts on the same day in a border area, but the NWS people are concerned that if the regional offices contradict each other, the people reading the forecasts will think they are probably both unreliable. It is more of a consumer confidence measure to preserve their own status and an authority than a duty to the public.
The problem is that if you live in VBNM County and search "ASDF Island" and you personally know that "ASDF Island" is in your county. But if Google comes back with results from ceb.wikipedia titled on the search engine page "ASDF Island (ZXCV County)"--you will think "That is completely wrong; of course it is wrong--its Wikipedia!" Several months ago I was confused and called up the county courthouse of the neighboring county to double check. The county employee was not pleased with me, from the nearby county, questioning the ownership of his county's island. He explained that it had always been part of his county. (I'm not an irredentist, really!).
If all the page titles were in Cebuano it would not be a problem, but location titles in many languages are frequently kept in their original languages. I would imagine that if the English Wikipedia titled their article "El Paso (Oklahoma)" the people who work on the Spanish Wikipedia would not be pleased that when Spanish speaking people type "El Paso" Google rings up both their wikipedia article on "El Paso (Texas)" and the enwiki article on "El Paso (Oklahoma)"--it would make people not take the es.wikipedia seriously. If the English speaking article was titled "The Pass (Oklahoma)" there would be no trouble to the Spanish speakers because only the English speakers would be led astray. But place names don't work that way. If one language gets it wrong, it confuses people searching Google in all the languages. So if there were thousands of errors like "El Paso (Oklahoma)" and "Mexico City (Honduras)" and the people managing the English speaking wikipedia only managed to fix a few every year, it would be reasonable for the people working on the es.wikipedia to want Google stop indexing all the non-curated English wikipedia articles.
Since some people have reservations with potentially granting censorship authority to the WMF, then as an alternative someone could translate a kindly request to the Cebuano wikipedia and ask them to no-index the geography pages tagged with the bot tag (it appears at the top of all the bot pages). If they are willing to do it on their own than all WMF would have to do is coordinate with Google to get the clones no-indexed too.--Epiphyllumlover (talk) 22:15, 12 June 2020 (UTC)
How about "El Paso (Baja Oklahoma)"? :-). Smallbones (talk) 23:35, 27 June 2020 (UTC)
Epiphyllumlover, you need to understand that the WMF does not control Google, and it's very unlikely that Google would take any notice of them over content on their own sites, and even more unlikely that it would over content on mirrors. Google does what it thinks is best for itself, which is to list the results of search queries according to its own algorithms, not some special pleading from the owners of web sites. Phil Bridger (talk) 20:19, 23 June 2020 (UTC)
So you are saying that it couldn't hurt to ask and that the WMF should do so? :) --Guy Macon (talk) 05:55, 29 June 2020 (UTC)
  • What evidence do we have that the search results are a problem for anyone in the real world? Simply being indexed in Google doesn't mean that your page will ever be shown to a real user. You'd need to find what kind of keywords, language and geography ever gets in the first page of results, and whether it displaces some more suitable result. Judging from the unique devices, with 100k "users" per month it's hard to believe there is any rampant excess visibility. The spikes of 500-600k might point to temporary changes in Google traffic. Nemo 06:04, 29 June 2020 (UTC)
That's the right question, I think. Because I check geographical names for Vicipaedia (Latin), I often look on Google for strange word combinations. I typically get a small number of results, with, somewhere in the list, Vicipaedias in unexpected languages -- e.g. Indonesian, because both Indonesian and Latin use the word "universitas". I never yet noticed Cebuano in my results, but, if I did, it would be because of a chance homonymy like that.
And, meanwhile, a Cebuano-speaking user of Google might actually want those pages and might improve one of them. There's no reason to prevent that. Andrew Dalby (talk) 13:03, 30 June 2020 (UTC)
Delete - GeoNames is absolutely not a reliable source of information. Anyone can add anything they want to GeoNames and it is subject to vandalism just like Wikipedia.[1] GeoNames is also a giant vacuum-cleaner of geographic databases and has no standards for inclusion. Even locations that were simply points in a geographic survey a hundred years ago can have entries in GeoNames. Finally, if a community doesn't have the resources to maintain a set of articles, they shouldn't have those articles. Not only does it erode Wikipedia's reputation for reliable information, but it pollutes the internet with endless copies and mirrors of bogus information. If the articles aren't deleted, I also support noindexing. Kaldari (talk) 14:24, 28 July 2020 (UTC)
Hi Kaldari, thanks for joining the discussion! Sorry for pestering you, but if you still have access to the Google Webmaster stuff then maybe you can check whether you have any partial answer to my doubts above. Nemo 15:55, 28 July 2020 (UTC)
@Nemo bis: I'm a real world-user, and it is terrible, and I have spent a few nights sorting out dupli- to quadruplicates, and daydreaming of create ways to hurt robots, if bots were actual hardware (dropping them off at IBM customer support is the cruellest idea so far).
I work with historical data, specifically I am trying to synchronise about a dozen databases of Shoah victims. That means, for example, finding out which of several Polish villages with the same name is someone's birth place, or if "Bad Freienwalde" and "Freienwalde" are the same (they are: one database uses historical names, others current, and "Bad" is like an honorary title that cities in Germany apparently get and lose depending on air quality or whatever).
I use Wikidata for this, with either custom software or OpenRefine. In principle, and for some countries, this works rather well. Except Wikidata tracks changes from cebwiki and creates items for every page. As a result, small places, especially in Germany, often have five or more identical entities. I am not exaggerating, just look at this atrocity: Kategoriya:Alemanya_paghimo_ni_bot. As but a single example, there are thirteen (update: eighteen, when the variant with double 'a' is included) pages for a place called Ach, which might be one or two, or maybe it's a river crossing through the region:

Aach (kapital sa munisipyo) Aach (lungsod) Aach (munisipyo sa Alemanya, Baden-Württemberg Region, Freiburg Region, lat 47,85, long 8,85) Aach (munisipyo sa Alemanya, Rheinland-Pfalz, lat 49,78, long 6,60) Aach (suba sa Alemanya, Baden-Württemberg Region, lat 47,73, long 9,23) Ach (suba sa Alemanya, Baden-Württemberg Region, lat 47,87, long 10,03) Ach (suba sa Alemanya, Baden-Württemberg Region, lat 47,93, long 9,64) [Ach (suba sa Alemanya, Baden-Württemberg Region, lat 47,95, long 9,82) [Ach (suba sa Alemanya, Baden-Württemberg Region, lat 48,40, long 9,80) [Ach (suba sa Alemanya, Bavaria, lat 47,57, long 10,15) [Ach (suba sa Alemanya, Bavaria, lat 47,58, long 10,68) [Ach (suba sa Alemanya, Bavaria, lat 47,65, long 10,80) [Ach (suba sa Alemanya, Bavaria, lat 47,70, long 11,16) [Ach (suba sa Alemanya, Bavaria, lat 47,78, long 11,11) [Ach (suba sa Alemanya, Bavaria, lat 47,82, long 10,55) [Ach (suba sa Alemanya, Bavaria, lat 48,73, long 11,06) [Ach (suba sa Alemanya, Bavaria, lat 48,76, long 11,57)[Ach (suba sa Alemanya, lat 47,90, long 10,12)

...and that's only the ones they helpfully added to the same category. There are duplicate categories, as well, with more Achs.
And this clearly isn't just a one-time mistake! Their attempts failed because identical titles can't be created, so they started adding "(city)" and "(town)" and so on. When they ran out of synonyms for cities, they just added geo-coordinates. The psychology that would compel someone to keep doing this, even though it is neither helpful nor lucrative nor appreciated is fascinating.
Delete sounds great. Thankfully, it does not seem to be ongoing right now, and svwiki has done a lot of work to clean up the mess the same user created there before they were banned. In the meantime, not synchronising with that pile of data that truly deserves the term dump is helpful to contain the damage, which Wikidata is actually doing as far as I can tell --Matthias Winkelmann (talk) 10:08, 12 August 2020 (UTC)


This is a new project under discussion.Feel free to discuss and share idea's about it.Tbiw (talk) 12:45, 15 July 2020 (UTC)

Technical Wishes Asking for Feedback on Template PrototypesEdit

In the 2019 WMDE Technical Wishes Survey, "Make working with Templates easier" was chosen as the focus area for the project for 2019-2021. Over the course of this year, the Technical Wishes team presented various prototypes on this topic and further developed the ideas with the initial feedback.

The first phase of prototype development is now complete and the team would be delighted to receive feedback on the ideas. To make giving feedback easier, you can now also share your opinion on-wiki with just a few clicks: a QuickSurvey per prototype on the project page.

Feedback - whether via the QuickSurveys, or by posting on the talk page - is welcome! The earlier feedback is received, the better. It will be incorporated into the planning of features to be implemented, and technical implementation is planned to begin imminently.

New project: Probabilistic Reasoning System utilizing Bayesian NetworksEdit

Let me introduce the already implemented and functional proof-of-concept PROVA Reasoning System. It is based on I hope it will be a good addition to Wikimedia projects. WikiProva


i dont know why am alwais rejetd i edit here with so much love--Aracatilar (talk) 23:27, 21 July 2020 (UTC)

@Aracatilar: You have never edited on meta. If you refer to English Wikipedia (different website), see w:en:User talk:Aracatilar for reasons. --Malyacko (talk) 20:06, 23 July 2020 (UTC)

OTF v. PackEdit

I don't think it was reported that Wikimedia Foundation joined this lawsuit to defend the pre-existing CEO of the Open Technology Fund (which gave some grants to NoScript, Tor and others):

EFF, Wikimedia, Human Rights Watch, Mozilla, the Tor Project, and a dozen more groups urged the U.S. Court of Appeals for the D.C Circuit in a filing to rule that Pack violated the First Amendment right of association and assembly and U.S. law —which both ensure that OTF is independent and separate from the government—when he ousted the fund’s president and bipartisan board and replaced them with political appointees. Government-funded OTF filed a lawsuit against Pack last month to stop the takeover.

The Wikimedia Foundation logo also appeared a while ago on (a letter to the USA House of Deputies), but that wasn't publicly announced yet so we don't know whether it was real or not. --Nemo 06:51, 25 July 2020 (UTC)

Note: They were mentioned at HTH, Quiddity (WMF) (talk) 00:38, 5 August 2020 (UTC)

Proposed new user group: Global blockerEdit

The local user group have following rights:

  • Lock or unlock global account (centralauth-lock)
  • Make and remove global blocks (globalblock)
  • Block other users from editing (block) (on Meta only)
  • Block a user from sending email (blockemail) (on Meta only)
  • Have one's own edits automatically marked as patrolled (autopatrol) (on Meta only; [2])

Main usecases:

  • Fight cross-wiki LTA
  • Allow a bot to global block known open proxies (such bot exists for blocking locally, but this also means it provides a proxy list for cross-wiki vandals; so existing bots should be migrated to global blockers)

Other usecases:

  • Rxy have a script that blocks/locks ISECHIKA sock. As there are concern about Rxy, it is better to move it to a dedicated bot account (either managed by Rxy or another trusted user), in case he will lost his stewardship
  • For local admins accepting an appeal, it can also remove the global lock unless there're other concerns
    • Note global locks happen almost always in clear-cut situations, so if a user successfully appealed a block in some wiki, it is no longer a good candidate for global lock (if there are controversy, global ban should be used)
    • However, compromised accounts, socks of community or foundation globally banned user may not be unlocked
    • Therefore, it will be necessary to make Global locks a policy; Global blocks should also be a policy

--GZWDer (talk) 10:23, 27 July 2020 (UTC)

Do we really have a need for this kind of group? -- CptViraj (talk) 10:45, 27 July 2020 (UTC)
  Comment@GZWDer There are more than one lock button behind global locks Spambots and LTAs often use proxies, and they also have to be blocked. This is what stewards do via LWCU. A group that can only block globally doesn't do much. Should such a group be introduced, this group should also be able to carry out corresponding LWCUs. Anything else would only result in locks with little effect.--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 18:11, 29 July 2020 (UTC)
So at some point we may introduce a global checkuser group (we will have this feature soon), but this proposal is useful even without it.--GZWDer (talk) 18:15, 29 July 2020 (UTC)
We have these groups already, they are called stewards. All the stuff that you require basically is stewards. Been there, done that. About the only limited scope and limited value is global blocking on an IP address (anonymous only, and short term only). I don't see the value proposition in the case presented to further splinter rights.  — billinghurst sDrewth 21:13, 29 July 2020 (UTC)
But Steward_requests/Global_permissions/2020-07#Global_sysop_for_Drmies is not a use case of stewards.--GZWDer (talk) 23:40, 29 July 2020 (UTC)
That matter is a person asking for global sysop and failing. If you cannot global sysop, and I doubt that you are going to get a global (b)locker right. If you have a sub-part of that discussion you would like to unpack, then go for it, but the request itself is not pertinent.  — billinghurst sDrewth 23:53, 29 July 2020 (UTC)
Exactly. If such a group is introduced, it has an equally high requirement and Crosswiki work is necessary.--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 14:18, 30 July 2020 (UTC)

Looks useless, if at all, the rights should be bundled with GS. --MF-W 14:22, 30 July 2020 (UTC)

  •   Support great reducing work of admins making other users get a task to do rather than daily edit.Tbiw (talk) 14:26, 2 August 2020 (UTC)
  •   Support, at least in part. I've long favoured unbundling rights from the steward group. Not everyone needs or wants full access to that toolset, or wants to undergo a month-long vetting process every year. I think making these rights part of global sysop would make sense. – Ajraddatz (talk) 15:28, 2 August 2020 (UTC)
    • This have to be a new local group - global sysop is not truly global and does not work for users mostly active in large wikis like Drmies.--GZWDer (talk) 16:13, 2 August 2020 (UTC)
      • Global sysop can be changed to whatever we want it to be, there are no technical restrictions on who it can be granted to. Even as a separate group, it seems highly unlikely that a user like Drmies would be granted access to globally-reaching tools without some knowledge or experience working at the global level. – Ajraddatz (talk) 16:37, 2 August 2020 (UTC)
  •   Support per Ajraddatz This would be useful as an extension for Global sysop, since IP addresses could also be blocked globally. Because global sysops work with stewards anyway and are always in contact, the above problem should not arise.--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬
  • Not 100% sure on this, but I don't really like the idea of giving this to GS. When people apply to GS, there is a review and commentary period about how such a candidate will do with the task of assisting small wikis; this would give them access to block every user on every project, and unlike global ip-blocks, local projects would not be able to override this. — xaosflux Talk 20:33, 2 August 2020 (UTC)
  • Local projects can disable global IP blocks locally, and scope of global lock don't allow controversial locks, hardly an account is unlocked by request, in proportion the accounts that are locked. Accounts that would be locked by this group are those whose motivation is clear and uncontroversial, like now by stewards. Rafael (stanglavine) msg 22:44, 3 August 2020 (UTC)
  •   Oppose. Absolutely not. The global sysop proposal passed by explicitly removing from the proposal global blocks. If this got added, then it means global sysops will be able to do actions affecting wikis where global sysops do not have access, radically changing the shape of the group, controversially. While the time has proven that much of the opposition to global sysops was FUD, this is an important addition that completly changes the scope of the global sysops. I also oppose a separate global/local group just for this. Global blocks and locks are the remit of the stewards. Cfr. Billinghurst. Regards, —MarcoAurelio (talk) 20:52, 2 August 2020 (UTC)
    • I don't think stewards are enough for fighting LTAs with cross-wiki presence. The SRG is already overloaded and it may be useful to give the right to some trusted local sysops in some wikis.--GZWDer (talk) 13:05, 3 August 2020 (UTC)
      • There is no upper bound on the number of stewards, if they feel they have a staffing emergency an election should be opened up. — xaosflux Talk 22:42, 4 August 2020 (UTC)
  •   Support --Novak Watchmen (talk) 23:00, 3 August 2020 (UTC)
  • I thinked about support attributing to GS, but the proposal is for a local group and GS is a global group so we would need to make adaptations, and Marco Aurélio's point is clear and I need to agree. As a separate group, I don't think that only rights to lock and block globally is so practical. Sometimes is necessary LWCU, delete pages in small wikis (spam, vandalism, etc.), so Global Blockers would need to ask for help (stewards or GS) in the same way. Really stewards have many functions, as Ajraddatz said, but they are correlated in day-to-day, so I don't know if splitting would be very useful, except in cases where functions can be performed in isolation, such as global-renamers and abuse filter managers. Rafael (stanglavine) msg 23:02, 3 August 2020 (UTC)
    • Block and lock are important tool for emergency. LWCU is not emergent at all.--GZWDer (talk) 19:48, 4 August 2020 (UTC)
  •   Strong oppose. Absolutely not. This would only make matters worse. The ability to coordinate locks with CU and OS is fundamental to it. Your cited case, Drmies, would not benefit from this, or would only make it worse. He'd be able to lock the account, but not to 1) OS the edits and 2) check and block the underlying IP to prevent the creation of yet another account that would continue the abuse. Regarding what you said above, Block and lock are important tool for emergency. LWCU is not emergent at all., that is completely wrong. Locking abusing accounts and doing nothing else to it will simply result in the creation of more and more accounts. To be fair, even doing that, LTAs jump IPs so they can keep abusing. —Thanks for the fish! talkcontribs 23:10, 4 August 2020 (UTC)
  • I wish this centralauth-lock and globalblock to be bundled with WM:ADMIN. Kind regards, — Tulsi Bhagat contribs | talk ] 03:37, 5 August 2020 (UTC)
    @Tulsi Bhagat: I think the wish never comes true. Why should sysops globally (b)lock users / IPs? This is far from the role of local sysops.--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 14:15, 5 August 2020 (UTC)
    @WikiBayer: Yeah! I think Meta-Wiki is more a global community and sysops here are more than an ordinary local sysops as in they have special actions with global effects. IMO, bundling centralauth-lock and globalblock to sysops here won't be an issue, undoubtedly this is home of LTAs and sysops should responsible as well to combat with them. We neither agree to create a separate global/local group (I personally also oppose to create a new group) nor bundling the rights to GS. Moreover, most of the sysops here are either Stewards or future Stewards or former Stewards. So, the alternative solution i see that the rights to be bundled with WM:ADMIN. This will definitely help decreasing the workload of Stewards. Kind regards, — Tulsi Bhagat contribs | talk ] 16:45, 5 August 2020 (UTC)
    For a short time, global locking was available to local bureaucrats. I would support those access being granted to Meta sysops as well, though I doubt there would be support for it. – Ajraddatz (talk) 16:54, 5 August 2020 (UTC)
  •   Strong oppose per Tks4fish and MarcoAurelio we do not need Steward Junior. Praxidicae (talk) 13:53, 5 August 2020 (UTC)
  •   Oppose as proposed largely per Marco. I’m very sympathetic to Ajraddatz’s points, but I think the issue is that as constituted, unless you entirely revamp the global rights system this would throw it out of whack. I might support that revamp (probably would actually), but only doing one piece wouldn’t work. There’s also the problem that SRGP, etc. is kinda a backwater where you have “global” insiders commenting, so there’s no real scrutiny to the level stewards get. To me it seems you’d want substantially more vetting than that. TonyBallioni (talk) 13:55, 5 August 2020 (UTC)
  •   Oppose. I am not convinced that this proposal fills a compelling need (i.e. it's not clear where the stewards have been inadequate to require this proposal), and I am concerned that without other LTA-combatting abilities in the steward/local administrator toolset, such as viewing deleted revisions, this new group may face challenges coming to informed global blocking decisions. Mz7 (talk) 13:58, 5 August 2020 (UTC)

some WMF bans will be appealableEdit

See Talk:Trust_and_Safety/Case_Review_Committee#Relation_with_WMF_Global_Ban_Policy: Once the commitee is set up, it will handle appeals of WMF bans.--GZWDer (talk) 11:16, 28 July 2020 (UTC)


Hi greetings, I have started a discussion regarding a new proposal on translations at Meta talk:Babylon#Academy for translations. I humbly request you to participate in it. Thank you.--Path slopu (talk) 11:08, 31 July 2020 (UTC)

Problem in the Oversight policyEdit

Info: I have started a Discussion at Talk:Oversight policy-𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬08:51, 3 August 2020 (UTC)

Wikimedia's association with Fandom / WikiaEdit

Although this is a problem I've had in the back of my mind for at least a couple of years, I never really considered posting about it here. My question is about Wikimedia's association with Fandom (aka Wikia). According to Wikipedia's article about the company,, "Wikia is not the commercial counterpart to Wikipedia", as stated by Wikimedia staff. So, then it would make sense there is no preferential treatment of Fandom over any other wiki farm out there, by Wikimedia's software MediaWiki. After all, there are plenty of competing platforms out there, not to mention several wikis being hosted by either an individual game publisher or an independent organisation created around an individual wiki, just to name a few examples I know of.

Now the problem I'm having is that there is a built-in wikilinking system — similar to w: prefixes for enwp, or mw: prefixes for, which all make complete sense to implement as Wikimedia's own projects — to link to Fandom wikis, which probably stems from the old days when it got founded by Wikimedia staff members. Just to show what my issue is, there is even inconsistency in linkability between two Fandom-owned platforms, and

Now, I don't expect every single commercial wiki platform out there to be incorporated like this into MediaWiki software. But, objectively speaking, there is no reason to seemingly endorse Wikia through implementing these wikilinks to their platform on every single current MediaWiki installation by default, without supporting their competitors as well (as shown in that example, the bigger of the two Minecraft wikis cannot be linked as easily as the . Other than backwards compatibility I see absolutely no reason to keep this wikilinking a possibility in mediawiki software.

My request is to either also support things like gamepedia:, which would then lead you down the rabbit hole of also supporting weirdgloop: for the RuneScape wiki family, and probably a whole list of other smaller wiki farms, or simply remove the support for wikia: wikilinking altogether.

To handle the breaking of existing wikilinks that use this prefix, there are plenty of solutions. Either a hidden category could be made to appear on every page that contains such a prefix, to phase in the deprecation of this prefix. Or an automated porting script could be run on installing a new version of MediaWiki (if the software supports such a thing). Or, the upgrade logs could simply notify anyone upgrading their wiki that this feature will no longer be supported due to Wikimedia's desire to be unbiased.

In my opinion, it's weird that Wikimedia has tried its very best to stay unbiased in every single way, yet keeps supporting this feature that directly associates the software produced by Wikimedia with a company from which Wikimedia has distanced itself. Joeytje50 (talk) 16:57, 5 August 2020 (UTC)

Interwiki links are kept at Interwiki map. There is no preference towards Wikia/Fandom, any site can have an interwiki prefix added if there is a need to link to it. – Ajraddatz (talk) 17:01, 5 August 2020 (UTC)
Or an automated porting script could be run on installing a new version of MediaWiki (if the software supports such a thing I don't think it does. I support the removal of Wikia: though. — Alexis Jazz (talk or ping me) 16:30, 14 August 2020 (UTC)

Technical Wishes: FileExporter and FileImporter become default features on all WikisEdit

Max Klemm (WMDE) 09:13, 6 August 2020 (UTC)