Page MenuHomePhabricator

Get rid of interwiki prefixes that are country codes instead of language codes (dk, jp, etc)
Open, LowestPublic

Description

(Another issue raised due to T74674)
http://dk.wikipedia.org redirecting to http://da.wikipedia.org appears to have been an anomaly from 2002 (see http://comments.gmane.org/gmane.science.linguistics.wikipedia.international/712), before the language committee and it was extended in T17357 to http://dk.wikibooks.org and http://dk.wiktionary.org despite the input of the language committee being very negative.

IMO it should be removed, so it can not be used any longer as an interlanguage link in content pages, which means wikitext parsers need to recognise 'dk' as an interwiki langlink prefix and know that it is equivalent to da, but only on three of the Wikimedia projects. Ugh!

Is there any other country code used as a subdomain on multi-lang projects that redirects to the language subdomain of that country?

But if this annoyance must persist, it would be a bit less annoying if it was consistently annoying.


http://dk.wikiquote.org
http://dk.wikivoyage.org
http://dk.wikinews.org

..all redirect to URLs like https://incubator.wikimedia.org/wiki/Wq/dk?goto=mainpage , which says

"dk" Wikivoyage (unknown language code). A Wikiquote in this language does not yet exist.

(another bug: there is html syntax in the title) with slight differences for Wikivoyage of course.


http://dk.wikisource.org redirects to http://wikisource.org/ ; it should go to https://da.wikisource.org/


http://dk.wikiversity.org/ says

This wiki does not exist. Unfortunately, Wikiversity in "dk" does not exist on its own domain yet, or it has been closed. You may like to visit Beta Wikiversity to start or improve dk Wikiversity there.

Event Timeline

jayvdb raised the priority of this task from to Needs Triage.
jayvdb updated the task description. (Show Details)
jayvdb subscribed.

Ah, other ones that exist:

  • jp -> ja
  • cz -> cs

bah, I agree with just getting rid of the country codes (unless it's a chapter wiki or so). I can think of others where we could add country codes. If we use country codes, then it makes sense to add others as well but.. that would just add more complexity again... So let's just remove these..

jayvdb renamed this task from dk subdomain redirecting to some Danish projects to country code subdomains redirecting to language projects (dk, ja, etc).May 9 2015, 11:30 AM

I guess these were actually created with the purpose of adding interwiki links when interwiki and DNS was created from the same file. These files are now separate and these codes were also recently removed from langlist as well.

Glaisher renamed this task from country code subdomains redirecting to language projects (dk, ja, etc) to country code subdomains redirecting to language projects (dk, jp, etc).May 9 2015, 3:19 PM
TTO lowered the priority of this task from Low to Lowest.May 10 2015, 3:04 AM
TTO subscribed.

What's the actual purpose of this task? At the moment it seems to be simply documenting the fact that these exist.

If the goal is to get rid of these interwiki prefixes, I doubt that is realistically going to be possible, unfortunately.

http://tools.wmflabs.org/pirsquared/iw.php?wikis=&iw=dk&hideclosed=on
http://tools.wmflabs.org/pirsquared/iw.php?wikis=&iw=jp&hideclosed=on

There seems to be somewhat heavy usage of these so I guess we can't just go ahead and remove these interwiki links..

It looks like many of these are interwiki links that havent been migrated to wikidata, and the reason is that they are an unknown language code.

In T87002#1274729, @TTO wrote:

What's the actual purpose of this task? At the moment it seems to be simply documenting the fact that these exist.

I was hoping they could be removed, or we add pages using these code to a maintenance category, or the codes that have been supported be supported on all projects, rather than just Wikipedia.

If the goal is to get rid of these interwiki prefixes, I doubt that is realistically going to be possible, unfortunately.

We have removed codes from the interwiki map before. Obviously we'd need to migrate all existing uses, and/or MediaWIki would need to be able to map deprecated codes to new codes so it can render old revisions. What else would be needed? Or why would there be no way this it is possible?

We have removed codes from the interwiki map before. Obviously we'd need to migrate all existing uses, and/or MediaWIki would need to be able to map deprecated codes to new codes so it can render old revisions. What else would be needed? Or why would there be no way this it is possible?

Well, it's not impossible, however, it does seem tedious, and not something I'm going to devote any effort to.

Also, these interwiki prefixes should work on all WMF sites. See for instance http://en.wikibooks.org/wiki/dk:Forside

TTO renamed this task from country code subdomains redirecting to language projects (dk, jp, etc) to Get rid of interwiki prefixes that are country codes instead of language codes (dk, jp, etc).May 11 2015, 2:14 AM
TTO removed a project: DNS.

Removed DNS project. The old URL redirects are condemned to stay around for eternity, I think.

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.

They shouldn't be used much in wikitext as interwiki links, but that can probably be fixed by bots or manually. The site configuration that allows this redirection should be preserved.

There's two separate things here.

This task is only about Thing 2. Your comment is mostly arguing in favor of keeping Thing 1

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

Their functionality should be preserved.