Like fr.w for French Wikipedia that will work all across other projects.
Description
Details
Related Objects
- Mentioned In
- T47116: Add all global sites as valid interwiki links
rMEXT353faf90bd77: Updated mediawiki/extensions Project…
rEWMA719504cc8177: Add b:, q:, n: etc as interwiki prefixes for all projects
rEWMA4514a3505d79: Add b:, q:, n: etc as interwiki prefixes for all projects
rEWMA31a9de85a255: Add b:, q:, n: etc as interwiki prefixes for all projects - Mentioned Here
- T47116: Add all global sites as valid interwiki links
T2955: b: doesn't work from Wikibooks; neither n: from Wikinews nor q: from Wikiquote, etc.
Event Timeline
For French Wikipedia you can use w:fr:. That should work across every single WMF wiki, including French Wikipedia itself. (If not, please let me know.)
In general w:xx: should work for Wikipedias. For other projects you will have to prefix the interwiki with m: to go via Meta. For example, for Vietnamese Wikibooks: m:b:vi:.
This is really an interwiki linking issue. Having T2955 fixed would help matters here a bit. Progress, such as code reviews, move at a glacial pace in the area of interwiki linking, so don't hold your breath.
Change 190642 had a related patch set uploaded (by TTO):
Add b:, q:, n: etc as interwiki prefixes for all projects
Redirecting to other domain than the domain what we want causes extra look ups and loosing back links to that domain.
also using [[w:fr:example]] on fr projects produces //fr.wikipedia.org/wiki/fr:example which will use 301 redirect, google sometimes will ignore status code on the target url (e.g. 404) and will count it as 200.
w:fr:$1 or :fr:w:$1 most goes to //fr.wikipedia.org/wiki/$1 in anywhere.
this prefixes can cause further issue so I suggest using fr.w without having to use : in the beginning.
I think the Google indexing concerns are rather trivial in the context of global user pages.
What "further issue" can w:fr: cause?
That doesn't answer my question. What is actually the problem with using w:fr: on a global user page? Can you point to an example of a page with this problem? If there is no problem, there is no need to "use direct url".
I've copied the short existing instructions from [[m:Help:Interwiki linking#Portable links]] into
https://www.mediawiki.org/wiki/Help:Extension:GlobalUserPage#Where_content_comes_from
and marked it all for translation.
As a fun hypothetical example, if you are in China and the English Wikipedia is blocked but the Chinese is not, using w:zh: won't work.
More realistically, redirects take time and make the site feel slower, and confuse some browser features like visited link colors. I guess still "rather trivial in the context of global user pages".
Don't forget to look for local pages with such prefixes before doint it. It would be a very nice idea to move them with suppressing redirect so that they would not be needed to be moved via API by pageid or via maintenance script.
@TTO read @Base's comment, that's what I was talking about at the first time.
@Tgr is also mentioned another issue, might exists with current way.
Also as I told, google ignores second 301, check this out:
https://www.google.com/search?q=site:en.wikipedia.org+inurl:en.wikipedia.org/wiki/fr:&start=10
Change 190642 merged by jenkins-bot:
Add b:, q:, n: etc as interwiki prefixes for all projects
Change 195464 had a related patch set uploaded (by Legoktm):
Add b:, q:, n: etc as interwiki prefixes for all projects
Change 195465 had a related patch set uploaded (by Legoktm):
Add b:, q:, n: etc as interwiki prefixes for all projects
Change 195465 merged by jenkins-bot:
Add b:, q:, n: etc as interwiki prefixes for all projects
Change 195464 merged by jenkins-bot:
Add b:, q:, n: etc as interwiki prefixes for all projects
[16:34:51] <logmsgbot> !log legoktm Synchronized wmf-config/interwiki.cdb: Updating interwiki cache (duration: 00m 05s)
@TTO: is this fixed now?