Hello,
today I have a Sunday support question to the linker and hooks experts.
I know Hook:LinkEnd and use this almost successfully in an extension to "tag" User and User_talk page with an additional attribute.
$wgHooks['LinkEnd'][] = 'wfWikiArticleFeedsAddSignatureMarker'; ... # https://www.mediawiki.org/wiki/Manual:Hooks/LinkEnd function wfWikiArticleFeedsAddSignatureMarker( $skin, $title, $options, $text, &$attribs, $ret ) { if ( $title->getNamespace() == NS_USER) { $attribs['userpage-link'] = 'true'; } elseif ( $title->getNamespace() == NS_USER_TALK ) { $attribs['usertalkpage-link'] = 'true'; } return true; }
This works perfectly as long as the page exists, but fail to add the attribute, if a "redlink" is created because the page does not exist.
I suppose that the getNamespace fails in this case, Perhaps a patch in Linker.php is required to set Namespace already if the page is non-existent.
Question: ======= How can I add my attribute as shown also for such links which point to a non-existing User or Usertalk page ?
On Sun, Feb 19, 2012 at 4:05 AM, Thomas Gries mail@tgries.de wrote:
I suppose that the getNamespace fails in this case, Perhaps a patch in Linker.php is required to set Namespace already if the page is non-existent.
I don't think so. Even non-existent Title object must have their namespace set. It's possible that your hook isn't called in this case, or called with strange parameters. I recommend putting in some debugging statements (var_dump and such) to check whether your hook is even being run and what its parameters are set to.
Roan
Am 21.02.2012 23:57, schrieb Roan Kattouw:
I don't think so. Even non-existent Title object must have their namespace set.
Yes, they have.
I have found the problem. It is not the Linker per se and come with a modified question. It has to do with i18n and localisation of the (in this case) names for USER and USER_TALK Namespace.
Basically: a link on a page like [[Benutzer:Alice]] is not necessarily the same as [[User:Alice]] (even when the latter exists).
It depends on the current setting of
$wgLanguageCode = "en" ; $wgLanguageCode = "de" ; (during testing my extension I played with this setting)
whether [[Benutzer:Alice]] it is in the Namespace or not.
So I was trapped by thinking that _any_ localised Namespace (like "Benutzer") is necessarily the same as USER or USER_TALK, which was incorrect.
Question: ======= Has anyone an idea, how to detect language-independently whether a link on page is in Namespace USER or USER_TALK, or in a localised version of these (when $wgLanguageCode has been modified)?
The goal is to detect and to mark USER or USER_TALK page links language-independently in function wfWikiArticleFeedsAddSignatureMarker in E:WikiArticleFeeds line 262 .
Tom
On 22 February 2012 08:28, Thomas Gries mail@tgries.de wrote:
Am 21.02.2012 23:57, schrieb Roan Kattouw:
I don't think so. Even non-existent Title object must have their namespace set.
Yes, they have.
I have found the problem. It is not the Linker per se and come with a modified question. It has to do with i18n and localisation of the (in this case) names for USER and USER_TALK Namespace.
Basically: a link on a page like [[Benutzer:Alice]] is not necessarily the same as [[User:Alice]] (even when the latter exists).
It depends on the current setting of
$wgLanguageCode = "en" ; $wgLanguageCode = "de" ; (during testing my extension I played with this setting)
whether [[Benutzer:Alice]] it is in the Namespace or not.
So I was trapped by thinking that _any_ localised Namespace (like "Benutzer") is necessarily the same as USER or USER_TALK, which was incorrect.
Question:
Has anyone an idea, how to detect language-independently whether a link on page is in Namespace USER or USER_TALK, or in a localised version of these (when $wgLanguageCode has been modified)?
The goal is to detect and to mark USER or USER_TALK page links language-independently in function wfWikiArticleFeedsAddSignatureMarker in E:WikiArticleFeeds line 262 .
Tom
Well if this were an on-wiki template I would suggest you normalise the namespace name to the localised canonical name using {{NAMESPACE:<page>}}, then compare it with a switch to the various similarly-normalised namespace names: {{#switch: {{NAMESPACE:<page>}} | {{ns:2}} = <it's a user page> | {{ns:3}} = <it's a user talk page> }}. Programatically you'd be able to cut out a lot of circularity in that process, just have a look at what code is used in the NAMESPACE: parser function and see what you can reuse.
Or, and I can't quite tell which you want from your comment, are you looking to detect when a link uses a prefix which is a User: namespace alias in *any* language, even when that prefix is not in use on the wiki? Why would you want to do that?
--HM
On Wed, Feb 22, 2012 at 12:28 AM, Thomas Gries mail@tgries.de wrote:
Basically: a link on a page like [[Benutzer:Alice]] is not necessarily the same as [[User:Alice]] (even when the latter exists).
It depends on the current setting of
$wgLanguageCode = "en" ; $wgLanguageCode = "de" ; (during testing my extension I played with this setting)
whether [[Benutzer:Alice]] it is in the Namespace or not.
So I was trapped by thinking that _any_ localised Namespace (like "Benutzer") is necessarily the same as USER or USER_TALK, which was incorrect.
Question:
Has anyone an idea, how to detect language-independently whether a link on page is in Namespace USER or USER_TALK, or in a localised version of these (when $wgLanguageCode has been modified)?
The goal is to detect and to mark USER or USER_TALK page links language-independently in function wfWikiArticleFeedsAddSignatureMarker in E:WikiArticleFeeds line 262 .
This sounds like it should be a non-issue. If the wiki language is set to English, then [[Benutzer:Alice]] simply is not a user page, it's in the main namespace. If the language is set to German, [[Benutzerin:Alice]] will be a user page, and [[Benutzer:Alice]] and [[User:Alice]] will be aliases pointing to that page.
Trying to detect German namespace prefixes while the wiki language is in English simply is not going to work, and *should not* work. If you have been changing the lanugage code settings around a lot, then maybe something got stuck in parser cache and that made it look like the detection failed?
Roan
wikitech-l@lists.wikimedia.org