Template talk:Main talk other

From Wikipedia, the free encyclopedia
  (Redirected from Template talk:File other)
Jump to: navigation, search

CSS namespace detection[edit]

For future reference and so I can link people to an example:

I have just discovered that some of the things we use {{main talk other}} for can be done in CSS only. MediaWiki sets the namespace number as a class in the <body> tag for the rendered pages. Thus we can use CSS to detect the namespace and show different looks on boxes.

Such CSS code has to be added as classes in for instance MediaWiki:Common.css, it can not be added as style="" parameters in page code. Below is a code example showing how to do it. If you want to test it you need to copy the CSS code to your own monobook.css.

/* Testing namespace detection. */
.davidbox {                      /* Any namespace */
    width: 80%;
    margin: 0 auto 1em auto;
    padding: .2em;
    border: 1px solid #aaa;      /* Other space colours */
    background: #f9f9f9;              
.ns-0 .davidbox {                /* Main (article) space */
    border: 1px solid #aaa;      /* Ambox colours */
    border-left: 10px solid #1e90ff;     
    background: #fbfbfb;              
.ns-1 .davidbox,
.ns-3 .davidbox,
.ns-5 .davidbox,
.ns-7 .davidbox,
.ns-9 .davidbox,
.ns-11 .davidbox,
.ns-13 .davidbox,
.ns-15 .davidbox,
.ns-101 .davidbox {              /* Any talk space */
    border: 1px solid #c0c090;   /* Brown talk space colours */
    background: #f8eaba;       

And here is a small table that uses the namespace detecting CSS code above:

<table class="davidbox">
<tr><td>Testing the davidbox namespace detection.

And here is how it renders:

Testing the davidbox namespace detection.

If you haven't installed the CSS code it won't look like much. But with the CSS code it will render as an ambox when on article pages, as a brown talk page message box when on any talk page and as a normal grey messagebox when on any other kind of page.

Neat, isn't it?

--David Göthberg (talk) 22:06, 12 April 2008 (UTC)

Using CSS based namespace detection has some drawbacks:
  • It makes it hard to demonstrate how a template looks on different types of pages. That is it is hard to emulate the "demospace" feature of our namespace detection meta-templates.
  • It makes it harder to use the same CSS classes for templates that only are meant to be used in one namespace. That is it is harder to stop them from changing appearance when demonstrated on for instance a talk page or listed on a "Wikipedia:" page. This is kind of the opposite of the "demospace" problem above.
  • The CSS code becomes slightly larger and more complex.
But it perhaps has one advantage:
  • It might save some server load. That is, page rendering becomes easier for the Wikipedia servers. However since the CSS code becomes slightly larger that means serving larger CSS files which might cost just as much or even more.
My conclusions for most usage cases so far have been that it is better to not use CSS based namespace detection. But I am still studying/investigating this.
--David Göthberg (talk) 12:10, 12 July 2008 (UTC)


What is the reason for using these templates? Why not just use the traditional method of directly using parser functions? --- RockMFR 16:38, 7 July 2008 (UTC)

These templates package the functionality into easy to use (and I hope) well documented templates. Since many/most template programmers do not know how to code namespace detection. Just like we package/hide functionality in other software into functions with good names, thus making the code easier to build and read. See for instance how we use {{category other}} in the {{CatDiffuse}} template.
Also, they supply the easy to use "demospace" functionality which is way harder to make without these templates.
--David Göthberg (talk) 17:21, 7 July 2008 (UTC)

Return nothing when no parameters[edit]

I have removed the "return namespace name" function from all these namespace detection templates. Since it is not used, not needed and it causes problems in some situations.

That is, I removed the code that returned the name of the namespace when these templates were used without any parameters. (Or with all parameters empty.) These templates now instead return an empty string (renders nothing) in this case. Before I removed the function I checked that no template or page was using these templates in that way.

--David Göthberg (talk) 13:06, 12 July 2008 (UTC)

Basepage-subpage detection template[edit]

We have now created the two pagename-detection templates suggested here. See {{basepage subpage}} and {{if pagename}}. --David Göthberg (talk) 02:55, 11 November 2009 (UTC)

I'm rather surprised you haven't done anything like this yet (that I can see), I've been kicking the idea around for awhile now of a template to automate the process of determining if a given page is a base page or a subpage - this would be very useful in userboxes, where often no such detection is used before categorizing pages the userbox is transcluded onto. Any thoughts? —Dinoguy1000 18:59, 22 October 2008 (UTC)

Oh, good idea! Sometimes the simple ideas are the ones hard to come up with. I think you are first with this idea. If I understand your idea right, then yeah, that would be useful in several situations. And I can easily code up such a template for you. Do you mean like this?
  • It considers these pages to be basepages: "User:Example" and "Template:Example"
  • It considers these pages to be subpages: "User:Example/test", "User:Example/test/test" and "Template:Example/doc"
So, what should we call the template? Perhaps {{basepage subpage}}? Sounds a bit weird, but I can't come up with any better name.
It should take two unnamed (numbered) parameters, and an optional "demospace" parameter like this:
{{basepage subpage
| Basepage text.
| Subpage text.
| demospace = base / sub
Or perhaps the demospace parameter should take the values "basepage" and "subpage"? The demospace parameter is of course mostly for its documentation and for testing.
What do you think?
--David Göthberg (talk) 15:50, 23 October 2008 (UTC)
It looks pretty good, though I agree about the name, I couldn't think of a good one either. =P As for the demospace parameter, why not just let it accept both sets? It'll be using a #switch anyways, right? I actually would have gone and coded up a sample myself, but I wasn't really clear on how to do the demospace parameter (although I suppose I could have just looked off of this template). One last thought, it would be interesting if the template could detect what level of subpage it's transcluded onto, but of course I don't see any real use for such a feature, and it's not even possible using just MediaWiki markup, ParserFunctions, and magic words AFAIK, so it's more me as a programmer thinking of a programming challenge. ^_^;; —Dinoguy1000 17:39, 23 October 2008 (UTC)
I learnt the hard way that it is a bad idea to let a template accept more than one name for a parameter. Since then you are stuck forever supporting that or doing a huge effort to fix all cases. Often it is easy to add now, but it makes it much harder to do changes in the future. And some users get confused and wonder if there are some difference in meaning between the two names for the same parameter.
Actually, we can detect what level a subpage is! By using the {{#titleparts:}} parser function. It is a little known but very powerful parser function. I have become pretty adept at using that one since I coded up the {{editnotice loader}} some week ago. If we have a need for multiple subpage levels then I know how we can have a nice syntax for how to feed the parameters to the {{basepage subpage}} template:
{{basepage subpage
| 1 = Basepage text.
| 2 = Subpage text, any level.
| demospace = basepage / subpage / subsubpage

{{basepage subpage
| 1 = Basepage text.
| 2 = Subpage text, first level.
| 3 =   <!-- Empty but defined parameter, means empty subsub level. -->
| demospace = basepage / subpage / subsubpage

{{basepage subpage
| 1 = Basepage text.
| 2 = Subpage text, first level.
| 3 = Subsubpage text, and for any level below that.
| demospace = basepage / subpage / subsubpage
And so on. And yeah, it would be cool if the template had that feature, but I too can't come up with a plausible usage case. And note that the syntax above is backwards compatible with the syntax for the simple version, so we can extend the template at a later time.
By the way, regarding hysterical functionality in templates. Have you seen {{namespace detect showall}}? I made that one since we actually have a need for it. Check out its List of all parameters at the bottom of its documentation. I didn't dare to put that list before the examples since I was afraid it would scare people too much... :))
Anyway, I will probably have some time to code up {{basepage subpage}} next week.
--David Göthberg (talk) 21:13, 23 October 2008 (UTC)
Cool, I never knew about #titleparts: before (even though I saw {{editnotice loader}} yesterday)! I'll have to play around with it some time. As for multiple param values, that is true, isn't it? In that case, I don't see the harm in using "basepage"/"subpage" in full. As for showall, all I can say is... yikes... that's almost as scary as the parameter lists for all the cite templates! BTW, for another case in which {{basepage subpage}} would be useful, I just finished creating documentation for {{Infobox animanga/Header}} that is meant to be transcluded both onto the template and onto the central documentation page, which involved basepage/subpage detection to conditionally transclude categories and interwikis, as well as to control the display of a message (clone of the "This documentation is transcluded from" line from {{documentation}}, vs. a {{notice}} about how documentation for the other components can be found). It was hard enough at first, but now that it's worked out, it should be fairly simple to do this for all the other components (although I'm awaiting comments on it ATM). —Dinoguy1000 21:35, 23 October 2008 (UTC)
Woho! That {{infobox animanga}} is scary! :))
My experience is that it is too messy to use parser functions in the documentation. It is messy for the one creating the documentation, and even more messy for later users that wants to update the documentation, and it wreaks havoc with interwiki link bots. Instead I use a much simpler and clearer approach. See how I have done with {{nowrap begin}} and its helper templates. Start by looking at the documentation for for instance {{•wrap}}.
--David Göthberg (talk) 22:48, 23 October 2008 (UTC)
Well, not so scary if you're used to tooling around with it (and occasionally breaking the crap out of it :ph43r: )... The problem with adapting your approach for documenting the nowrap family is that they are a group of closely related, but largely distinct, templates whose use is rather simple and straightforward (and not heavily interdependent), while each component of the Infobox animanga family (except Header2 and Footer) has a number of parameters that must be documented, and it's thus not unusual to have to refer to the documentation to see how something should be used or why something isn't working like you want - even if you're more familiar with the templates than the back of your hand. When doing so, both with the current system and with the one you have set up for the nowrap family require two clicks and some scrolling, or three clicks - or opening a new tab and typing a URL by hand. The whole reason I proposed the current system was to eliminate this problem. I'm quite aware of the trouble people (and bots) have with funky ParserFunctions on documentation pages, and I'm perfectly prepared to deal with such problems manually in exchange for the extra convenience my proposed system would offer. Of course, if anyone else has suggestions for a better method that offers the same benefit, I'm all ears. =) —Dinoguy1000 18:13, 24 October 2008 (UTC)
Then you have not understood the benefits of the system that I use. The first click is not costly since it only loads a very small /doc page. And the link on the small /doc page can be an anchor link, thus the second click can take you directly to the right section in the main documentation. Thus no manual scrolling needed.
Anyway, I have been thinking more about the {{basepage subpage}} template. For some time now I have been thinking of making the related {{doc other}} template. It was intended to work like this:
{{doc other
| Text for /doc pages.
| Text for any other pages, both basepages and subpages.
| demospace = doc / other
But then I realised I would need a separate template for each subpage name in use, like /testcases and /Editnotice and so on. And that would be messy. But then I realised that I can do a template that can take any subpage name as parameter. So it would look something like this:
{{if pagename
| /doc = Text for /doc pages.
| /something = Text for any pagename that ends in "/something".
| other = Text for any other pages, both basepages and subpages.
| demospace = ...
Dinoguy1000: But you pointed out that there are cases when we need to differentiate between basepages and subpages. And I think we sometimes might need to detect specific subpages at the same time. So then we would need something like this:
{{if pagename
| /doc = Text for /doc pages.
| /something = Text for any pagename that ends in "/something".
| basepage = Text for any basepage.
| subpage = Text for any subpage.
| other = Text for any other pages, both basepages and subpages.
| demospace = ...
It would pattern match from top to bottom, so if the "/doc" parameter is fed and the template is on a "/doc" page it will not show the data from the "subpage" parameter. And if both "basepage" and "subpage" is used then "other" has no meaning.
I am also thinking of perhaps instead of the "basepage" and "subpage" parameters use two parameters like this:
{{if pagename
| /other = Text for any subpage.
| other = Text for any pages. But not for subpages if "/other" was fed.
But that is perhaps a bit more complicated for people to understand? But for me that feels cleaner.
I have several other things I am thinking of adding to that template, mostly involving some nifty pattern matching on basepage names.
And yes, I know how to code all this! The only thing I am worried about is that people are going to abuse this template to make way too complex things...
Dinoguy1000: What do you think? Would you have use for such a template?
--David Göthberg (talk) 17:21, 25 October 2008 (UTC)
Actually, the boilerplate link on several of the components is an anchor link (see e.g. /Anime or /OVA). ;) It's just not consistently done at this time. As for your examples, I'd have to say that the /other vs. other example is harder to understand than the sample above it - and what if you have a subpage literally named "{{PAGENAME}}/other"? In addition, I think that probably 90% of transclusions are only going to need to distinguish between basepages in general vs. subpages in general, so the template should support simple {{template name|basepage=text|subpage=different text}} usage. Other than that, my only thought is what if you *want* more than one parameter to display its contents (e.g. you have text that should be displayed on all subpages, but you have another message that should be displayed on a specific subpage, in addition to the specific message)? I suppose in such a case, you could just duplicate the generic message in the parameter for the specific subpage, though. And what about the backslash? Would that be required, and what would happen if it was omitted? (and one last thought, since you seem like you might know, could you explain on my talkpage how substitution detection works? I've tried to follow the code for it in templates, but can't quite figure it out (not that I've tried very hard =P )) —Dinoguy1000 17:46, 25 October 2008 (UTC)
Ah, okay. I admit I haven't fully studied your documentation system.
Right, the "/other" name would be reserved and thus could not be used to detect a subpage called "/other". But as you say, using the "basepage" and "subpage" parameters might be easier for people to understand.
And if you want both the "subpage" and the "/doc" messages to display at the same time on /doc pages then I would do like this:
{{if pagename
| subpage = Text for any subpage.
}}{{if pagename
| /doc = Text for /doc pages.
And right, the slash in the "/doc" parameter would be required, since otherwise it would interfere with the basepage pattern matching I am thinking of adding. (I didn't tell the details of that part before.) Well, a lower-case "doc" probably wouldn't interfere. But feeding an upper-case "Doc" would match pages such as "Template:Doc", "Template talk:Doc" and "User:Doc".
And regarding the unrelated subject of substitution detection: I don't understand that either. I have spent a lot of time reading up about that and done some experimenting, but still I don't really understand it. And since I dislike substitution and think it should almost never be used, and substitution detection causes very messy code, I decided to simply not bother about substitution detection.
--David Göthberg (talk) 19:10, 25 October 2008 (UTC)
Well, the original boilerplates predate me joining Wikipedia, so that's not really "my" documentation system... ;) Of course, just call the template twice... Funny how the simplest solutions aren't always the most obvious. =P Okay, don't worry about substitution detection then, I still want to learn it, and I'll just have to figure out who else might know how it works (the easiest way would be to either ask or look through the history of a template that uses subst detection). —Dinoguy1000 16:46, 27 October 2008 (UTC)

So DG, have you gotten any time to poke at this yet? *is still caught slightly off-guard whenever David is called "DG"* —Dinoguy1000 21:18, 15 December 2008 (UTC)

Sorry no, since I am now on a wikivacation and don't know when I will be back. I just popped in here for some days to do some planned updates, among other things due to that the namespace "Image" has been renamed to "File". But since I have now reread all what we wrote here: I think we should do two templates. A "simple" one named {{basepage subpage}}, and a much more complex one named perhaps {{if pagename}}. Sure, the complex one could do everything that the simpler one can do, but for users that only need the {{basepage subpage}} it would mean much easier documentation to read. Just as I have done with the namespace detection templates.
--David Göthberg (talk) 03:32, 5 February 2009 (UTC)
That's fine, everyone needs a break now and then. ;) Two templates would be fine with me, too - most cases would only need the simpler setup, so there's no reason to provide all the functionality in those cases. ダイノガイ?!」(Dinoguy1000) 03:44, 5 February 2009 (UTC)
We have now created the two pagename-detection templates suggested here. See {{basepage subpage}} and {{if pagename}}.
--David Göthberg (talk) 02:55, 11 November 2009 (UTC)
To be fair, David is the one who actually coded the templates - {{basepage subpage}}'s code is easy enough to understand, but I would have to look at {{if pagename}} for a good long while before I felt confident about how it does the pagename matching voodoo (and for further attribution, David stated that he actually got the inspiration for that code from some that User:Amalthea showed him a week or so ago). =) ダイノガイ千?!? · Talk⇒Dinoguy1000 06:38, 11 November 2009 (UTC)

I need another language version of this Template[edit]

I need a another language version of this Template, and I need the source code. What should I do now? --Gantulgaas (talk) 12:26, 28 October 2008 (UTC)

This is going to sound rude, but I promise I don't mean to be rude:
Oh dear, if you don't even know how to view the source code of this template, then you either need to spend some month to learn the basics of Wikipedia editing and template programming, or you need to contact some template knowledgeable editor on your own language Wikipedia.
The source code is available as usual by going to Template:Main talk other and then click the [view source code] tab at the top of the page. That's the same tab that usually says [edit this page] when a page is not protected.
But I checked, I see that this template was installed on your home Wikipedia two days ago: mn:Template:Main talk other. You should probably talk to mn:User:Latebird since he/she was the one that installed it on your language Wikipedia.
--David Göthberg (talk) 12:57, 28 October 2008 (UTC)

Move Template:Image other[edit]

When will the template be moved to Template:File other? --Joshua Issac (talk) 14:53, 14 December 2008 (UTC)

YesY Done - {{image other}} moved to {{file other}}, its code slightly updated and documentation and subpages updated accordingly. I have also updated {{namespace detect}} and {{namespace detect showall}}. I am the main coder of the namespace detecting templates, but I have been (and really still are) on a wikivacation.
--David Göthberg (talk) 02:56, 5 February 2009 (UTC)

Gerson Chicarelli[edit]

Yes check.svg Resolved.

Where does the last line of this template come from?

 --Gerson75 (talk) 23:24, 23 December 2008 (UTC)copyright:gerson chicarelli 2008

...and who is Gerson Chicarelli, why does s/he holds a copyright? Or, more likely: how to stop this weirdo, as its name shows up on a few different places as well... (talk) 14:14, 28 January 2009 (UTC)

Can you link to some pages where you see that? I can't find anything wrong with any of the namespace detecting templates. (Of course, since that was some days ago some other editor might already have found the bug and fixed it.)
--David Göthberg (talk) 03:00, 5 February 2009 (UTC)
It's gone now in this article/template, Someone must've fixed it. I did so for a few others, googling for '"gerson chicarelli" wikipedia' should give a few places where s/he added this copyright line. There were other wikis with this line added too.
-- (talk) 02:30, 23 February 2009 (UTC)

((talkspace detect))[edit]

This message is mostly for Hornoir, since I want to make major changes to the {{talkspace detect}} template he created. But ideas and comments from anyone else is of course always welcome.

Last month Hornoir created the {{talkspace detect}} template with similar functionality as the {{namespace detect}} template, but with the purpose of separating different talk spaces instead of different subject spaces. ("Subject space" is MediaWiki jargon for all the non-talk spaces.) I think he choose a very good name for it, and we probably need such a template. But I want to do a major rework of it so it becomes compatible with the other namespace detection templates.

1: I want to add a "demonspace" parameter, since that is one of the most useful features in the other namespace detection templates. That means when we build other templates with them we can easily test and demonstrate how those templates will behave when in different namespaces, already when doing testing in a /testcases subpage. And we can demonstrate their different looks in their template documentation.

2: The demospace parameter needs to be fully parameter compatible with the other namespace detection templates. Since some templates out there use more than one of the namespace detection templates at the same time. A single template might use say {{main other}}, {{talk other}} and {{talkspace detect}} at the same time. Thus it must be possible to feed say "demospace=user talk" to a template and when it in turn internally feeds that to the namespace detection templates they all should understand "user talk" correctly. That is currently not the case with some of these namespace detection templates, so I am planning to fix that. (Several of the ns templates currently consider an unknown demospace parameter such as "user talk" to mean "other" type, instead of "talk" type.)

3: I want to rename the parameters in {{talkspace detect}} from for instance "user=" to "user talk=" and so on. Since I think the data parameters should have the same naming as the demospace parameters. That is currently the case for all the ns templates except for {{talkspace detect}}, since it uses "user = User talk page text", instead of "user talk = User talk page text". This will become strange when we have "demospace = user talk" and have to feed the data as "user = User talk page text". (And yes, we can have spaces in parameter names here at Wikipedia!)

4: I want to rename the "default" parameter to "anytalk". Since I think the naming of the "default" parameter is confusing, since it only covers the talk spaces and since in all the other ns templates the "other" parameter is the actual default parameter. So I think that "anytalk" instead is a better name for the "catch all talk-spaces parameter".

5: If we call the "catch all talk-spaces parameter" in {{talkspace detect}} "anytalk", then we should perhaps consider renaming the "talk" parameter in {{namespace detect}} to also be called "anytalk". To keep these templates parameter-compatible. But perhaps that is a bit overkill? I'll have to think about that for a while.

6: I want to make the "other" parameter in {{talkspace detect}} work the same as in the other ns templates. It should mean any namespace not specifically fed, both talk spaces and subject spaces. That is, it should be a catch-all default parameter.

7: If we have a "default/anytalk" parameter, and the "other" parameter is changed to mean all namespaces, then we still would have use for a parameter to only catch all the subject spaces. I suggest we name that one "anysubject" or perhaps simply "subject". The spelling of "anysubject" is slightly awkward, but it is clear. Also consider that we might add the same parameter to {{namespace detect}} some day, and then "anysubject" is perhaps clearer over there. But "subject" is shorter and nicer, so it's a tough choice, so I'd like some feedback from the rest of you.

I already have working code for all this in the /sandbox of {{talkspace detect}}. Also see the examples in /testcases.

Everyone: Please do not go ahead and do these changes, since all these templates are already deployed and used. So it's a bit tricky to do these changes without breaking any usage out there. You can leave it to me to do these updates, since I know how to do it. And we need to give the people who watch this page some time to think about the parameter naming and discuss it (consensus), before we go ahead.

--David Göthberg (talk) 13:05, 18 March 2009 (UTC)

I have no problems with any of the suggested changes, David. I am, unfortunately, out-of-town at the moment and won't be back home for five days. Since this template is used in the {{HorrorWikiProject}} banner (which I created it for) that will need to be updated to reflect the new naming conventions; if you wish to institute the changes prior to my return, please also update the banner template. Otherwise, I will update the banner template… Thanks again.
P.S. I prefer "anytalk" and "anysubject" since they convey the same feel and implied meaning. hornoir (talk) 11:32, 19 March 2009 (UTC)
Thanks for the go-ahead. And yes, I will update the {{HorrorWikiProject}} banner too, so nothing will break. So, have a nice trip and CU around later.
I have been thinking of some alternative names for the two talk/subject parameters: "anytalk" could also be called "other talk", and "subject/anysubject" could be called "other subject". Not sure what I prefer...
--David Göthberg (talk) 18:41, 19 March 2009 (UTC)
Thank you kind-like. While "other talk" makes perfect sense on the template, "other subject" does not — since it does not allow for separate parameters for each subject space. hornoir (talk) 11:14, 20 March 2009 (UTC)
Ah, good point. So it has to be "anysubject". And "anytalk" is anyway shorter and sweeter than "other talk".
And "anytalk" also works for {{namespace detect}} for the same reason. And "anytalk" still works for {{namespace detect}} even if we some day extend that template to separate talk spaces.
I changed the example in the section below to show "anysubject" and "anytalk". But looking at it I think we could perhaps use "any subject" and "any talk" with spaces instead? But not sure. Sorry to be a pedant, but once we deploy a parameter name we tend to be stuck with it forever.
--David Göthberg (talk) 19:05, 20 March 2009 (UTC)
I'm thinking the most direct and straightforward — on {{talkspace detect}} — would be "other talk" and "namespace", since they are very descriptive parameters. I like things that I can remember without having to revisit a templates documentation every time I use it. hornoir (talk) 10:50, 21 March 2009 (UTC)
Now I don't understand you at all. I thought you preferred "anytalk" and "anysubject". Since "other subject" is a bit weird since there is only one subject parameter. And since the talk parameter is the corresponding parameter for the talk spaces then the talk parameter should be called "anytalk". And "anytalk" works even when there are all the other talk parameters.
Note that I mean we should also have a parameter named "other", which covers all namespaces (both talk and subject spaces). Similar to the example below and like we do in all the other namespace detection templates.
But what do you mean that "namespace" should mean? I can't see any sane use of a parameter named "namespace" in the {{talkspace detect}} template.
--David Göthberg (talk) 02:10, 23 March 2009 (UTC)
Whoops, that's just a result of quick typing (I can only connect to the internet for an hour or two until I'm back home). I meant "other talk" and "anysubject" in talkspace template and reverse in namespace. Sorry about that. hornoir (talk) 11:01, 23 March 2009 (UTC)
Ah yeah, your point is logical. However, I think it will be easier to remember and clearer if both begin with "any", as in "anytalk" and "anysubject". (Or perhaps "any talk" and "any subject" with spaces.) And I think "any" works fairly well in all the cases in both {{talkspace detect}} and {{namespace detect}}. So our points of view differ slightly on this. I guess we should ask some other editors to come here to get some more input on this.
--David Göthberg (talk) 21:14, 23 March 2009 (UTC)

Adding talk spaces to ((namespace detect))[edit]

I am thinking of adding the talk space detect functionality to {{namespace detect}}, thus it could separate all namespaces. That would make {{talkspace detect}} redundant. To illustrate what I mean, here is what {{namespace detect}} would say at the top of its documentation:

{{namespace detect}} detects and groups all the different namespaces used on Wikipedia into several types:
main = Main/article space, as in normal Wikipedia articles.
user, wikipedia, file, mediawiki, template, help, category and portal = The other namespaces except the talk pages.
anysubject = Any subject space (non-talkspace) that were not specified as a parameter to the template. See examples below.
talk = The talk pages of articles.
user talk, wikipedia talk, file talk, mediawiki talk, template talk, help talk, category talk and portal talk = The rest of the talk spaces.
anytalk = Any talkspace that were not specified as a parameter to the template. See examples below.
other = Any namespaces that were not specified as a parameter to the template. If both other talk and other subject are used then this parameter has no effect.

But I am worried this might make the documentation of {{namespace detect}} so bloated that most template programmers will have a problem to understand what this template does.

--David Göthberg (talk) 19:52, 19 March 2009 (UTC)

I originally contemplated requesting an extension of the namespace detect template, but decided against it for a similar reason: (1) it would make one template bloated when it was unnecessary, since the same can be achieved by calling the namespace detect template inside of the talkspace detect template. hornoir (talk) 11:14, 20 March 2009 (UTC)
Yeah, they can be used inside each other if needed. And I guess that will only rarely be used. So you are probably right, no need to extend {{namespace detect}}.
I have been thinking of changing the "talk" parameter in {{namespace detect}} to "anytalk", to make it parameter compatible with {{talkspace detect}}. And perhaps also add the "anysubject" parameter. But I think I won't do any of that, at least not for now.
--David Göthberg (talk) 19:05, 20 March 2009 (UTC)

"Book" and "Book talk" space[edit]

Some hours ago the new namespaces "Book:" and "Book talk:" were added to the English Wikipedia. I have now checked all these namespace detection templates and done updates where needed. I have also checked some of the major templates that are using these templates.

Most of the namespace detection templates were not affected by this change, and those detecting "any talk" space already had generic code that also worked for the new "Book talk:" space. Most of these templates detected "Book:" as type "other" during the transition.

Here is the bugzilla bug about the adding of the new namespaces: bugzilla:21958. And the discussions that led to the adding of these namespaces: Wikipedia:Village pump (proposals)#Namespace for books (will later be moved to /Archive 56 or so) and Wikipedia:Village pump (proposals)/Archive 45#Namespace for books.

--David Göthberg (talk) 03:41, 30 December 2009 (UTC)

Transclusions of {{template other}}[edit]

Can someone please explain why {{template other}} has such a high transclusion count, as seen here Wikipedia:Database reports/Templates transcluded on the most pages and here Special:WhatLinksHere/Template:Template_other? Is it possible that the transclusion counter is not properly omitting text within the <noinclude> tags? Set theorist (talk) 22:35, 17 April 2012 (UTC)

Namespace and associated talkspace detection template[edit]

Do any of the {{Namespace detect}} style templates allow detection for a NS and associated TS? I have a template I am building that I want it to be able to pull the


if in the User: or User_talk: NS, and skip that section otherwise. This feels harder to describe than it actually is. User:Technical 13   ( C • M • Click to learn how to view this signature as intended ) 19:21, 26 March 2013 (UTC)

Switch of mbox templates and category handler to Lua[edit]

I've made a request over at Template talk:Mbox about switching all of the {{mbox}} family templates, plus the {{category handler}} template, to use Lua modules. These templates have millions of transclusions, so I would appreciate comments and some more eyes on the code. Please let me know what you think over at the request page. — Mr. Stradivarius ♪ talk ♪ 15:10, 15 October 2013 (UTC)


Is it time to switch to Lua? --Edgars2007 (talk/contribs) 07:29, 18 August 2014 (UTC)

@Mr. Stradivarius:? --Edgars2007 (talk/contribs) 11:59, 20 August 2014 (UTC)

Draft ns[edit]

Does not serve draft ns. Sort of nullifies |demospace=. -DePiep (talk) 23:35, 27 December 2014 (UTC)