From T36098#392361:
(In reply to comment #11)
The preferred way to link to translatable pages is not to link directly to the
page anyway but to use Special:MyLanguage.Which causes [[Special:WhatLinksHere]] not to show it. Is this already
tracked?
As internal links are not registered, Special:RecentChangesLinked is also made useless for all translatable pages.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Record links that go via Special:MyLanguage in links table | mediawiki/core | master | +25 -2 |
At least the link with Special:MyLanguage/ should be registered at its base page name (everything after the / in that prefix), because it is the source of translations, which should exist, independently of the number of subpages for language codes (which will vary constantly over time).
As well translated subpages will most often have a navbox linking to all other languages, either from a template (this links are registered), or the list autogenerated by <language/> (these links are also not registered).
Change #1196945 had a related patch set uploaded (by Jon Harald Søby; author: Jon Harald Søby):
[mediawiki/core@master] Record links that go via Special:MyLanguage in links table
Would you consider doing the same for Special:TalkPage/ ? I added a feature request for this somewhere...
Why don’t you just use the magic word [[{{TALKPAGENAME}}]] instead of [[Special:TalkPage/{{FULLPAGENAME}}]] or the parser function [[{{TALKPAGENAME:pagename}}]] instead of [[Special:TalkPage/pagename]]? The special page is great for usage outside the wiki (where one doesn’t know how to construct the talk page name), but within the wiki, the parser function works fine, and causes no issues with backlinks (nor with tools like Page-Previews or Navigation-Popups-Gadget – I haven’t tested them, but I suspect they have problems with links pointing to special pages).
[[Special:TalkPage/]] was introduced based on a specific use case. That means a similar situation exists in the database (even if you think [[Special:TalkPage/]] shouldn't exist), and has therefore to be dealt with.
The method I used in the patch could be expanded to cover several redirecting special pages; I was also thinking Special:EditPage and Special:History (and possibly several other redirecting special pages) might be worth including. However, Special:TalkPage would require special handling, since the target specified as the subpage (e.g. Testpage in Special:TalkPage/Testpage) probably isn't the same as the actual target (Talk:Testpage), so we would have to get the title of the talk page somehow.
Yes, and that specific use case is constructing the URL on the client side: T242346: Add special page to redirect from subject page to talk page. It’s a great solution for that use case (I do appreciate it existing), but that use case doesn’t involve parsing pages, and thus what you ask wouldn’t help it.