Last modified: 2014-09-24 01:12:16 UTC
It would be very useful, for things such as the Opinions: namespace on WikiNews and the Citations: namespace on Wiktionary to have the ability to add new tabs to the skin for every page in a namespace, either before or after the Talk: tab. They should work in the same way as that, but go to other namespaces. This would then lead to one Talk: page common across the namespaces that are linked up in this way.
Created attachment 6677 [details] A hard patch Here is an early copy of a patch. It may need add the variable it uses in the GlobalSettings.php file. But that is another decision area. There is a guide on how to use it here: http://www.mediawiki.org/wiki/User:Svippong/AdditionalTabs
Currently this kind of thing can be done by using the SkinTemplateNavigation hook to modify the 'namespaces'. (For backwards compat you can add something to SkinTemplateTabs too, it's 1.18 when SkinTemplateNavigation starts to apply to all SkinTemplateSkins)
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
+need-review, inferring that svip wants feedback on the patch's approach
Robin, could you give svip some feedback?
The patch is quite old and would probably need to be adapted to current MediaWiki. But there's also a new bug about the same issue, see bug 42214.
*** Bug 42214 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > *** Bug 42214 has been marked as a duplicate of this bug. *** Okay, what this needs is a plan of action going forward. I've started an RFC here: <https://www.mediawiki.org/wiki/Requests_for_comment/Custom_inter-namespace_tabs>. I'm removing "patch-need-review" and adding "easy". This bug is pretty easy to resolve, it just has a few unanswered implementation questions. This is why it needs an RFC to hammer things out properly.
Please review: https://gerrit.wikimedia.org/r/#/c/37569/
(In reply to comment #8) > (In reply to comment #7) > > *** Bug 42214 has been marked as a duplicate of this bug. *** > > Okay, what this needs is a plan of action going forward. I've started an RFC > here: > <https://www.mediawiki.org/wiki/Requests_for_comment/Custom_inter- > namespace_tabs>. > > I'm removing "patch-need-review" and adding "easy". This bug is pretty easy > to > resolve, it just has a few unanswered implementation questions. This is why > it > needs an RFC to hammer things out properly. I decided to comment on your RFC. I hope I am doing it right!
I've submitted a patch into Gerrit about a month ago, and nobody reviewed it. Is there anybody out there? https://gerrit.wikimedia.org/r/#/c/37569/
The second take on this: https://www.mediawiki.org/wiki/Extension:NamespaceRelations Needs one tiny fix to be merged into core to support queries (like editintro in Wikinews): https://gerrit.wikimedia.org/r/#/c/43118/. Request for new repo is pending.
What's the status of this? Appropriate patches are merged, is there anything else left to do here?
(In reply to comment #13) > What's the status of this? Appropriate patches are merged, is there anything > else left to do here? No answer - assuming everything is fine.
(In reply to comment #14) > (In reply to comment #13) > > What's the status of this? Appropriate patches are merged, is there anything > > else left to do here? > > No answer - assuming everything is fine. Sorry, I think it should be set FIXED if deployed. The NamespaceRelations has a huge flow: if a page is moved, the page in a tertiary namespace is not moved. I believe the extension should not be deployed until I/anyone issues a patch that introduces this feature. As from what I have seen in MovePage (correct me if I misspelled it), it's a mess of code and needs a lot of love. I'll be looking into it soon to have the feature described above implemented.
(In reply to comment #15) > Sorry, I think it should be set FIXED if deployed. FIXED refers to merged into the codebase in Bugzilla. Deployment schedule can be found at https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap
(In reply to comment #16) > (In reply to comment #15) >> Sorry, I think it should be set FIXED if deployed. > > FIXED refers to merged into the codebase in Bugzilla. It seems particularly unwise to argue with the person who's been actively working on this bug and to whom the bug is currently assigned as to whether the bug is fixed or not. This bug probably needs a few more dependencies (to cover, for example, the page move issue mentioned in comment 15). wizardist: if you could file any dependent bugs, that would be great. > Deployment schedule can be found at > https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap Please do not link to irrelevant pages. There's nothing on that page that has anything to do with this bug. This feature is being implemented in an extension, not in MediaWiki core, and this extension has not yet been installed on Wikimedia wikis. The MediaWiki 1.22 roadmap, interesting as it is, currently has no bearing here.
(In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #15) > >> Sorry, I think it should be set FIXED if deployed. > > > > FIXED refers to merged into the codebase in Bugzilla. > > It seems particularly unwise to argue with the person who's been actively > working on this bug and to whom the bug is currently assigned as to whether > the bug is fixed or not. If there is still codework to do that has not been done yet (and that seems to be the case as per latest comments), this bug report should indeed remain open. (If all required patches had been *merged* into the code repository but not *deployed* yet on Wikimedia servers, this bug report should be RESOLVED FIXED.) > This bug probably needs a few more dependencies (to cover, for example, the > page move issue mentioned in comment 15). wizardist: if you could file any > dependent bugs, that would be great. Yeah, that would definitely make it easier to see where we're at. :) Sorry for the confusion created here.
Removing the 'easy' keyword. Extension is apparently written and awaiting code review, which is definitely not 'easy'.
