Template talk:Main talk other

To help centralise discussions and keep related topics together, the talk pages of its sister templates, such as {{main other}} and {{file other}}, redirect here.

Template:Main talk other is permanently protected from editing because it is a heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit template-protected}} to notify an administrator or template editor to make the requested edit. Usually, any contributor may edit the template's documentation to add usage notes or categories.

Any contributor may edit the template's sandbox. This template does not have a testcases subpage. You can create the testcases subpage here.

Text and/or other creative content from this version of Template:Main_other was copied or moved into incubator:Template:Wp/nod/main_other with this edit. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists.

Archives

Archive 1 (2008 March - )

CSS namespace detection

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.
</table>

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)[reply]

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)[reply]

Purpose?

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)[reply]

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)[reply]

The one line of documentation does not make it clear (to me, anyway) what situations this template should be used in, or what it does. -Pete Forsyth (talk) 19:05, 6 April 2021 (UTC)[reply]

Just realized where I was -- my comment was about {{Draft other}} whose talk page redirects here. -Pete Forsyth (talk) 19:06, 6 April 2021 (UTC)[reply]

Return nothing when no parameters

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)[reply]

Basepage-subpage detection template

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)[reply]

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? —Dino guy 1000 18:59, 22 October 2008 (UTC)[reply]

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)[reply]

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. ^_^;; —Dino guy 1000 17:39, 23 October 2008 (UTC)[reply]

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)[reply]

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). —Dino guy 1000 21:35, 23 October 2008 (UTC)[reply]

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)[reply]

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. =) —Dino guy 1000 18:13, 24 October 2008 (UTC)[reply]

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)[reply]

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 )) —Dino guy 1000 17:46, 25 October 2008 (UTC)[reply]

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)[reply]

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). —Dino guy 1000 16:46, 27 October 2008 (UTC)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

I need another language version of this Template

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)[reply]

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)[reply]

Move Template:Image other

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

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)[reply]

Gerson Chicarelli

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... 88.217.39.117 (talk) 14:14, 28 January 2009 (UTC)[reply]

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)[reply]

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.

-- 62.216.211.18 (talk) 02:30, 23 February 2009 (UTC)[reply]

((talkspace detect))

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Adding talk spaces to ((namespace detect))

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)[reply]

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)[reply]

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)[reply]

"Book" and "Book talk" space

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)[reply]

Transclusions of {{template other}}

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)[reply]

Namespace and associated talkspace detection template

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

{{lc:{{{1|{{Gender:{{#titleparts:{{BASEPAGENAME}}|1}}|m|f|o}}}}}}}

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)[reply]

Switch of mbox templates and category handler to Lua

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)[reply]

Lua?

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

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

Draft ns

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

Draft support for Namespace detect showall

This edit request to Template:Namespace detect showall has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Sync {{Namespace detect showall/sandbox}} with {{Namespace detect showall}} please. I'd do it, but it's cascade protected.Headbomb {t · c · p · b} 03:21, 22 August 2018 (UTC)[reply]

@Headbomb: the test cases aren't very clear on this - it looks like an "other" output is expected and that other templates may be dependent on the output of this template? Do you have more background? — xaosflux ^Talk 01:12, 23 August 2018 (UTC)[reply]

@Xaosflux: Per doc, you have three 'general' types. Mainspace, talk space, and the catch-all other space. Other can then be overidden by a specific space, on a case-by-case basis. The sandbox works, as far as I've been able to test it. Headbomb {t · c · p · b} 01:16, 23 August 2018 (UTC)[reply]

@Headbomb: do you have examples of other templates that are dependent on this one? — xaosflux ^Talk 01:28, 23 August 2018 (UTC)[reply]

The one I tested on was {{Draft article/sandbox}}, which invokes the sandbox of this template, and I tested it on a variety of namespaces (template, draft, mainspace, userspace, etc...). But see [1] for more. Headbomb {t · c · p · b} 01:30, 23 August 2018 (UTC)[reply]

Easier to review is simply the diff. All it does is add the draft namespace, plus expands the number of codes you can have. Headbomb {t · c · p · b} 01:33, 23 August 2018 (UTC)[reply]

Noting here that I've downscaled this template to template protection, as it wasn't widely used. Jo-Jo Eumerus (talk, contributions) 13:18, 25 August 2018 (UTC)[reply]

Updated. Headbomb {t · c · p · b} 06:33, 26 August 2018 (UTC)[reply]

Protected edit request on 22 March 2019

This edit request to Template:Draft other has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please remove the line <noinclude>{{pp-template|small=yes}}</noinclude> - protection templates are automatically handled by the documentation page. Thanks, --DannyS712 (talk) 06:42, 22 March 2019 (UTC)[reply]

Done — JJMC89 (T·C) 07:06, 22 March 2019 (UTC)[reply]

Requested move 18 November 2019

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this section.

It was proposed in this section that multiple pages be renamed and moved.

decision:
No consensus. See no general agreement below to rename these templates. As is usual with a no-consensus outcome, editors can strengthen their arguments and try again in a few months to garner consensus for name changes. Kudos to editors for your input, and Happy Publishing! (nac by page mover) PI Ellsworth ed. ^put'r there 01:16, 9 December 2019 (UTC)[reply]

Links: current log • target log

This is template {{subst:Requested move/end}}

– For about a decade now, we've been moving templates to names that make more sense in plain English (and keeping shortcuts as redirects), to cut down a little on the intense editorial learning curve. The current name of the template suggests this has something to do with linking to other talk pages, and is just very unintuitive. It's a template for determining if the current page is a talk page or an "other" and displaying different text depending on what the answer is. Updates: I later noticed the parent template {{Main talk other}} and have added it; then added more based on comments below. — SMcCandlish ☏ ¢ 😼 23:44, 19 November 2019 (UTC) —Relisting. — Martin (MSGJ · talk) 11:19, 28 November 2019 (UTC)[reply]

@SMcCandlish: {{Book other}}, {{Category other}}, {{Draft other}}, {{Main other}}, {{File other}}, {{Help other}}, {{Module other}}, {{Portal other}}, {{Template other}}, {{User other}}, {{Wikipedia other}}. --Gonnym (talk) 14:34, 18 November 2019 (UTC)[reply]
{{testcases other}}, {{sandbox other}}, {{subpage other}} ‑‑Trialpears (talk) 23:53, 18 November 2019 (UTC)[reply]
Added. — SMcCandlish ☏ ¢ 😼 23:41, 19 November 2019 (UTC)[reply]
Comment: I can get the desire to "make more sense in plain English". Then, shouldn't the name pattern be: Template:Namespace Template or other, Template:Template page or other page? Also, this motivation suggests that the names better be replaced (as in edit mode is where most editors meet them). Is this part of the move proposal? (sort of deprecation?). -DePiep (talk) 07:51, 20 November 2019 (UTC)[reply]
@SMcCandlish: could you reply to this? -DePiep (talk) 15:31, 22 November 2019 (UTC)[reply]
Well, we want them to be concise, too. The precision principle is that titles should be as precise as necessary, and no more. My proposed names are probably precise and long enough for what the templates do / are for, while the original names are just confusing. We have all kinds of template shortcuts in use in content, including in mainspace (e.g. {{cn}} and so on) that are opaque to readers and noob editors, but which resolve to the real and more transparent template names, so it doesn't seem to be problematic. And we have some bots and AWB scripts that bypass such redirects over time (as part of a more substantive edit, per WP:BOT policy). That said, I don't have any objection to something like the second of the alternative patterns; they're not so long-winded as to be all that non-concise, and they are just a bit more clear. However, wouldn't {{Template page or other}}, {{Testcases page or other}}, etc. work and be a tad shorter? I don't see the point of repeating "page" when we already know that's the context. The first alternative pattern I don't think works well; "Namespace Template" seems to mean "a template pertaining to namespaces" (and we probably have a category of those). A disambiguation that results in another ambiguity is a failure, as I often say. :-) I suppose that applies to my own initial "minimal change" proposal, since some of the results, like {{Wikipedia or other}} aren't very clear. — SMcCandlish ☏ ¢ 😼 23:56, 22 November 2019 (UTC)[reply]
Comment: I tend to agree with DePiep that if we are going to move them to a name that completely makes sense, then an option similar to one of the two they gave is a better solution. --Gonnym (talk) 12:06, 20 November 2019 (UTC)[reply]
What about {{Template page or other}}, {{Testcases page or other}}, etc., as a compromise? — SMcCandlish ☏ ¢ 😼 23:56, 22 November 2019 (UTC)[reply]
Support this one. If DePiep's proposes any alternative, please ping me and let me know. --Gonnym (talk) 15:19, 6 December 2019 (UTC)[reply]
Support per nom. Rationale seems reasonable. Only reservation was whether the proposed naming convention was the best; I think it's certainly better, but since consensus can change, if we feel something is better at some point in the future, we can always move again. Also, I assume nom wants the move done with redirects suppressed? Doug Mehus T·C 16:05, 20 November 2019 (UTC)[reply]
Why not "something is better at some point in the future" being now? As it stands, I don't think current "plain English" goal is not achieved. Oh and what is Redirect suppression? -DePiep (talk) 17:46, 20 November 2019 (UTC)[reply]
Sure; I'm trying to meet ya half-way on that, above. Dmehus: No I wasn't seeking to have redirs suppressed, or every mention of the templates at their extant names would have to be replaced, a pointless make-work exercise that seems to be behind Trialpears's objection, below. (DePiep: redirect suppression is something admins and page-movers can do – move a page without leaving a redirect behind from the old name to the new. This is generally only done in round-robin moves, and when moving a keepable page away from a policy-violating name, and for a few other technical reasons like speedy renaming of a recently created page that has an obvious and implausible typo in it). — SMcCandlish ☏ ¢ 😼 23:56, 22 November 2019 (UTC)[reply]
Oppose while the idea behind it is good, I think this will just lead to a big headache with a few editors insisting on not using redirects in templates. Dealing with that mess is more than enough for it to outweigh the minor benefits theoretically gained by this move. ‑‑Trialpears (talk) 22:27, 22 November 2019 (UTC)[reply]
I'm not entirely certain I follow you. This doesn't have anything to do with redirects in templates, but redirects to templates. If you mean that someone may want to change template X to reference {{talk or other|...}} instead of what would be its redirect {{talk other}}, who cares? It won't change the template functionality, and if someone wants to hard-core WP:GNOME that much, it's harmless and it saves us the hassle of them inflicting their OCD on something more troublesome, like the exact grammatical structure of hard-fought sentences at Donald Trump or whatever. :-) By the oppose reasoning you've presented, we should just never, ever rename a template, since some other template somewhere might have been using it at the original name. Yet we rename templates all the time. Anyway, see above about some alternative patterns. — SMcCandlish ☏ ¢ 😼 23:56, 22 November 2019 (UTC)[reply]
I see where you're coming from and would fully agree that these are non issues in most cases, but I think it's different when renaming several templates with millions of transclusions, several thousand of which are in template space. I would rather avoid having to deal with a flare up of the redirects in templates debate, especially since I'm not sure if the new name would be much better. If there would be a rename how about using {{if main}} like is done with {{ifsubst}}? At least for me that seems clearer. ‑‑Trialpears (talk) 01:26, 23 November 2019 (UTC)[reply]
I could go with that; I guess the one three-way template would be "if main or talk"? I don't really care what the pattern is as long as it makes sense and isn't confusing gibberish. The large number of transclusions is something a bot can clean up; other than writing a bot job, it needs no human interaction to deal with it. We have redirs in templates all the time, but it can matter when it comes to templates that are used so frequently that they the extra parser call of a redir might push some very long and complex articles past the transclusion limit. So, I don't object to replacing redirs in templates; it's just usually not a concern, and in the cases where it is, we could fix it manually in absence of a bot to do it. — SMcCandlish ☏ ¢ 😼 10:07, 28 November 2019 (UTC)[reply]
Oppose. I see no compelling reason for this change, and share Trialpears' concerns. The Wikipedia:File names guideline lists a limited number of good reasons for changing a file name, and advises "As a matter of principle, it is best to leave all files with generally valid names at their locations, even if slightly better names may exist." I think the same approach should be taken in template namespace, as with files, these names are not reader-facing. I recall that {{Main}} was named {{Main article}} for a time, which resulted in WP:COSMETICBOT drama, which causes real damage to editors' reputations, as so-called cosmetic edits were made to change {{Main}} → {{Main article}} and then back again, reminiscent of The Sneetches' Star-On and Star-Off machines. As to the idea of making names make more sense in plain English, that goal should be balanced by the goal of conciseness or brevity – we have template documentation for a reason – one cannot expect the function of the more complex templates to be fully described simply by their names. And "intense editorial learning curve" considerations should be balanced by the fact that we have a large number of editors who are familiar with the current names, who will be inconvenienced by the need to take extra time to look up the function of what will appear to be a new template the first time they see the new name. And I'm not sure who is more "OCD"... the "hard-core" Sneetch gnomes who bypass redirects, or Sylvester McMonkey McBean (the Fix-It-Up Chappie) who leads them to that behavior. – wbm1058 (talk) 15:23, 30 November 2019 (UTC)[reply]
That's completely irrelevant; WP:File names is about files (images, video, audio) and has nothing to do with any other form of page name. — SMcCandlish ☏ ¢ 😼 09:06, 6 December 2019 (UTC)[reply]

Wow, invoking WP:File names is really reaching. That has absolutly nothing to do here. Also, one cannot expect the function of the more complex templates to be fully described simply by their names - go read any programming language best practice for naming convention and you'll see how wrong you here (and Templates are code). Also Trialpears's argument is also not relevant here. Pages get renamed all the time, such is the wikipedia life-cycle. If we stopped moving pages just because we don't want to clean up after (which no one is forcing anyone else to do), then we can close down WP:RM. --Gonnym (talk) 15:19, 6 December 2019 (UTC)[reply]
"close down WP:RM"? Now, who's really reaching? The focus of RM is discussing article titles (mainspace), which has "nothing to do" with either files or templates. OK, Naming convention (programming). The choice of naming conventions can be an enormously controversial issue, with partisans of each holding theirs to be the best and others to be inferior... shorter identifiers may be preferred as more expedient, because they are easier to type... longer identifiers may be disfavored because of visual clutter. It is an open research issue whether some programmers prefer shorter identifiers because they are easier to type, or think up, than longer identifiers, or because in many situations a longer identifier simply clutters the visible code and provides no perceived additional benefit. This isn't that cut-and-dried. I respect that you make valid points, but I just don't think the missing "or" is that big a deal. It seems pretty clearly implied to me. wbm1058 (talk) 04:25, 7 December 2019 (UTC)[reply]
Nope, that's also wrong. RM is used for almost all rename processes (even project space), except where some other process has been codified (e.g. for stub tags, which are handled at WP:CFD because stub categories move with them to match, and moving categories around is a more complex process than changing a template's name). — SMcCandlish ☏ ¢ 😼 13:21, 7 December 2019 (UTC)[reply]
The focus of RM is discussing article titles doesn't mean that mainspace is the only namespace discussed here. WP:RMNOT lists the exceptions. I'm quite aware that templates, modules and project space moves are discussed here, and some of those discussions are worth it; alas, in my opinion, others are unproductive distractions which suck attention from fixing things in mainspace that are actually broken. wbm1058 (talk) 16:41, 8 December 2019 (UTC)[reply]

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Protected edit request on 30 April 2020

This edit request to Template:Main other has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Security and Intelligence Services (India) to SIS Group Enterprise Kcom2020 (talk) 11:25, 30 April 2020 (UTC)[reply]

Not done: this is the talk page for discussing improvements to the template {{Main talk other}}. Please make your request at the talk page for the article concerned. Jack Frost (talk) 13:05, 30 April 2020 (UTC)[reply]

Fully protected edit request on 6 December 2021

This edit request to Template:Main other has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

A protected template, {{Main other}}, needs a minor change to the comment. Please modify it as follows:

from this:

{{documentation}}
<!-- Add categories and interwikis to the /doc subpage, not here! -->
</noinclude>

to this:

{{documentation}}
<!-- Add categories to the /doc subpage; interwikis go to Wikidata, thank you! -->
</noinclude>

While this edit does not change the template's function, the comment is there for informational purposes to show editors where to put categories and interwiki links. This is especially important for inexperienced editors, and the old comment might be confusing to them. Thank you in advance! P.I. Ellsworth - ed. ^put'r there 10:00, 6 December 2021 (UTC)[reply]

Done — xaosflux ^Talk 16:08, 10 December 2021 (UTC)[reply]

To xaosflux: thank you and the Very Best of Holidays to You and Yours! P.I. Ellsworth - ed. ^put'r there 21:40, 10 December 2021 (UTC)[reply]

Fully protected edit request on 17 January 2022

This edit request to Template:Talk other has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

(Please see above.) A protected template, {{Talk other}}, needs a minor change to the comment. Please modify it as follows:

from this:

{{documentation}}
<!-- Add categories and interwikis to the /doc subpage, not here! -->
</noinclude>

to this:

{{documentation}}
</noinclude>

While this edit does not change the template's function, the comment is there for informational purposes to show editors where to put categories and interwiki links. This is especially important for inexperienced editors, and the old comment might be confusing to them. Thank you in advance! P.I. Ellsworth - ed. ^put'r there 09:26, 17 January 2022 (UTC)[reply]
I would prefer just to remove the comment, especially on protected templates which are only edited by experienced editors. What do you think? — Martin (MSGJ · talk) 18:38, 18 January 2022 (UTC)[reply]
@MSGJ: hmmm, seems like the iw "used to" go on the /doc page as well, which is not protected. — xaosflux ^Talk 18:54, 18 January 2022 (UTC)[reply]

To editors Martin and xaosflux: removing the comment is acceptable, of course, and the only problem would be in the future if this template becomes unprotected. An inexperienced editor might then place a category on the template rather than on the /doc page. You do what you think is best, Martin. P.I. Ellsworth - ed. ^put'r there 22:11, 18 January 2022 (UTC)[reply]
How long are we going to keep reminding editors to put interwikis go to Wikidata? That change was a long time ago now. — Martin (MSGJ · talk) 13:03, 31 January 2022 (UTC)[reply]

Then by all means, remove the misguiding comment. I've altered this request above. P.I. Ellsworth - ed. ^put'r there 19:10, 31 January 2022 (UTC)[reply]

Done. For the record I was thinking aloud and not intending to veto the request — Martin (MSGJ · talk) 21:52, 4 February 2022 (UTC)[reply]

To editor Martin: thank you! and excellent work fixing WP:Contact us btw; wish I had thought of that. P.I. Ellsworth - ed. ^put'r there 09:17, 5 February 2022 (UTC)[reply]

Protected edit request on 26 September 2022

This edit request to Template:Main other has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Change Kew College to Kew College Prep as page title Ninadiringer (talk) 09:53, 26 September 2022 (UTC)[reply]

Not done: this is the talk page for discussing improvements to the template {{Main talk other}}. If possible, please make your request at the talk page for the article concerned. If you cannot edit the article's talk page, you can instead make your request at Wikipedia:Requests for page protection#Current requests for edits to a protected page. EnIRtpf09b^{chat with me} 10:32, 26 September 2022 (UTC)[reply]

Requested move 29 November 2022

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: moved per request on my talk (permalink). ~~no consensus.~~ Discussion has been open for over a month. ~~Due to low participation, it is difficult to determine if there is consensus that "Project" is a clear enough synonym for the namespace.~~ (non-admin closure) Rotideypoc41352 (talk · contribs) 16:28, 4 January 2023 (UTC) and modified 20:24, 4 January 2023 (UTC)[reply]

Template:Wikipedia other → Template:Project other

– The current title is rather, well, Wikipedia-centric. 🙃 Especially given that these templates are likely to end up on other wikis by way of template imports, the name "Wikipedia other" is unclear and confusing; the generic "Project other" is less so. 「ディノ奴千？！」^{☎ Dinoguy1000} 01:24, 29 November 2022 (UTC) — Relisting. GeoffreyT2000 (talk) 05:07, 8 December 2022 (UTC) — Relisting. echidnaLives - talk - edits 06:21, 2 January 2023 (UTC)[reply]

Comment: This will require a template editor or sysop to close it if successful, as the page is protected. echidnaLives - talk - edits 06:12, 16 December 2022 (UTC)[reply]
Weak oppose. Not a big deal either way, but it seems to me that it'd be even more confusing for the template not to match the name used for the namespace itself, which is Wikipedia. I'm not especially worried about the effect on other projects since they can simply move the template in accordance with their own guidelines if desired. (I actually wouldn't be averse to renaming the Wikipedia namespace altogether, at least in principle, but that's obviously a much bigger discussion.) Extraordinary Writ (talk) 00:22, 19 December 2022 (UTC)[reply]
@Extraordinary Writ: did you know... [[Project:RM]]: Project:RM. wbm1058 (talk) 03:45, 30 December 2022 (UTC)[reply]
Support. Per Wikipedia:Project namespace the WP: namespace has also been called the "project namespace" from the onset, and since copying enwiki templates to other wikis has become more and more common, there is no harm for us to try to be helpful to the other wikis with our template page titles. As long as the current title continues to redirect to the new title, this name change should not be controversial. P.I. Ellsworth , ed. ^put'r there 18:53, 19 December 2022 (UTC)[reply]

Relisting comment: This RM isn't getting much attention, so I think a relist will be good here. echidnaLives - talk - edits 06:21, 2 January 2023 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Namespace detect: doc please

"This template returns ..." missing in documentation.

Could someone add to the {{Namespace detect/doc}} what it returns? That is, what is the result of its detection? Preferably, and expected, in the first line. Options can go in second paragraph.

I had to read the doc for this, but did not succeed nor did my test are test results clear. Also, not clear what mainspace effect is. Opening line "This is the {{Namespace detect}} meta-template." is not needed. DePiep (talk) 08:31, 26 February 2023 (UTC)[reply]

@DePiep: See Template:Namespace detect#Usage: it returns a text string. For example, the code

{{namespace detect|template=This is used on a template page|talk=This is used on a talk page|other=This is used on another page}}

, when used on this page, returns This is used on a talk page. --Redrose64 🌹 (talk) 09:49, 26 February 2023 (UTC)[reply]

Allow me to sigh. From the start, the examples in there skip the notion of which parameters (ie, predefined then? What with ns=blank?) are used. An initial sentence saying "This template returns X" not needed? And do you still think the very first sentence helpful?

BTW, the nature of my question is that the reply should be in the doc itself, not in a pingend reply; I was not looking for clarification of existing /doc TBH. (And I don't want to bother editors to explain doc to me personally).

There is more. The top section is not clear; how can one understand detection result "The remaining namespaces ... Any namespaces that were not specified", in the same list even? And, I think (after 2hrs of working with this) parameter(s) are required.

I think my question is: shall we improve these /doc issues? DePiep (talk) 10:06, 26 February 2023 (UTC)[reply]

Where do you see ns=blank? --Redrose64 🌹 (talk) 10:58, 26 February 2023 (UTC)[reply]

In about 6M pages in mainspace.

Anyway, since I cannot get you into the core question, I unfollow this page and skip /doc editing. Maybe a next experience may be different. DePiep (talk) 12:00, 26 February 2023 (UTC)[reply]

@DePiep: I can find lots of instances of "ns", and also of "blank", but I cannot find a single case of "ns=blank". If you make such claims, you should be able to point to some examples. If you cannot, and I can't find any, I can only conclude that none exist. --Redrose64 🌹 (talk) 19:27, 26 February 2023 (UTC)[reply]

That's not my point. You have diverted half a dozen times from my core question. I am not gonna spend time on this, and also I am not asking nor expecting you to waste time this way. DePiep (talk) 19:38, 26 February 2023 (UTC)[reply]

Fully protected edit request on 15 May 2023

This edit request to Template:Draft other has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

A protected page, Template:Draft other, needs a minor update. Please change its ending lines:

from this:

{{documentation}}
<!-- Add categories and interwikis to the /doc subpage, not here! -->
</noinclude>

to this:

{{documentation}}
<!-- Add categories to the /doc subpage; interwikis go to Wikidata, thank you! -->
</noinclude>

or remove the comment if you think it's no longer needed:

{{documentation}}
</noinclude>

Thank you in advance! P.I. Ellsworth , ed. ^{put'er there} 11:01, 15 May 2023 (UTC)[reply]

Not done for now: Please feel free to make the change in the sandbox. I don't see a reason to modify a page transcluded 100k times just to remove a possibly out of date comment that no-one sees besides those making a change to the page. Izno (talk) 21:52, 18 May 2023 (UTC)[reply]

Aliases

Hello! Does this template work with aliases? On arywiki, it seems that {{User other}} doesn't detect if the namespace is an alias (we have a technical issue that makes some old user pages appear with the old namespace string, which was kept as an alias, instead of the new one). Ideophagous (talk) 12:14, 23 December 2023 (UTC)[reply]

@Ideophagous: Are you asking about Template:Main talk other, or one of the other templates (Category other; Draft other; File other; Help other; Main other; Main talk other flex; Namespace detect; Namespace detect showall; Portal other; Project other; Talk other; Talkspace detect; Template other; User other; Wikipedia other) whose talk pages redirect here? --Redrose64 🌹 (talk) 17:28, 24 December 2023 (UTC)[reply]

@Redrose64: My issue was with the equivalent of {{User other}} on arywiki, which was copied from enwiki. But the question can be applied to the other templates. I've amended {{User other}} to take the alias of the User namespace on arywiki, into consideration but I'm wondering if there's a more general and portable solution that's not language or project dependent. Ideophagous (talk) 18:34, 24 December 2023 (UTC)[reply]

@Ideophagous: The easiest way of testing it is to put the code

This is {{user other|User|another}} namespace

into pages in various namespaces - preview, don't save, and see what it displays.

The code of Template:User other as it stands on enwiki can be copied unchanged to any other language's wiki and it will work as intended without further amendment. This is because of the line:

  | {{#ifeq:{{NAMESPACE}}|{{ns:User}}

notice that it doesn't use the word "User" directly, it passes it through the {{ns:}} parser function which localises it to whatever has been set up as the non-English name for the namespace. In other words, this edit shouldn't have been necessary. --Redrose64 🦌 (talk) 00:04, 25 December 2023 (UTC)[reply]

I did test it implicitly with {{User sandbox}} in my sandbox and it failed to recognize my user page (until I made the modification in {{User other}}), because it still uses the old namespace string, contrary to most other user pages on arywiki (this is a bug I have just reported on Phabricator). I think {{ns:User}} only returns a single value which is the main string of the namespace, not the aliases, which is consistent with the usage of switch. Ideophagous (talk) 08:30, 25 December 2023 (UTC)[reply]

Where you write my sandbox, which actual page is that? What was the exact code that you used in that sandbox? --Redrose64 🦌 (talk) 10:44, 25 December 2023 (UTC)[reply]

Protected edit request on 18 July 2024

This edit request to Template:Main other has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Change Vance to Jivani in sentence before footnote 38, as person treating for cancer. Mauimsk88 (talk) 01:40, 18 July 2024 (UTC)[reply]

@Mauimsk88:

Not done: this is the talk page for discussing improvements to the template {{Main talk other}}. Please make your request at the talk page for the article concerned. --Redrose64 🌹 (talk) 08:37, 18 July 2024 (UTC)[reply]