User talk:Davidgothberg/Pgn

About this template

I created this template since we had a problem that several of the archive templates didn't work correctly in the "Category talk" and "Help talk" namespaces. The reason is that those namespaces don't properly support subpages. This template works around that bug. We have discussed this issue at Wikipedia:Village pump (technical)/Archive 59#Subpage feature, and requested that the Mediawiki system admins fix the problem. But there is no telling when they are going to fix it, so I went ahead and created this template. Besides, this template is useful for more things than just working around the subpage bug.

When I created this template all the good names for it such as {{page}} and {{pagename}} were already taken, so I instead settled for the short name {{pgn}} as in "pagename".

I am planning to add several more features to this template.

--David Göthberg (talk) 22:18, 22 April 2009 (UTC)

Titleparts

Er, {{#titleparts:{{FULLPAGENAME}}|1}}??

• {{#titleparts:Foo/bar|1}} → Foo
• {{#titleparts:Talk:Foo/bar|1}} → Talk:Foo

{{#titleparts:Category talk:Foo/bar|1}} → Category talk:Foo

In fact, the only issue is that is recognises subpages in namespaces where they don't actually

{{#titleparts:File:Foo/bar|1}} → File:Foo

But that's nowhere near as severe a problem. Happy‑melon 22:08, 22 April 2009 (UTC)

I expected someone to bring up the parser function titleparts. But titleparts doesn't solve the problem. It is just a string manipulation function that can pick apart a string where there are slashes "/".

Titleparts doesn't do what {{BASEPAGENAME}} does. Titleparts can't give you all levels except the last one, unless you add a lot of complex if-cases. Consider if you are on the page "Talk:A/B/C", {{BASEPAGENAME}} then gives you "Talk:A/B". But {{BASEPAGENAME}} doesn't work in all namespaces. While {{pgn|basepage}} works in all namespaces.

And with titleparts it is hard to get the actual subpage, since you might not know how many levels down you are. Consider if you use it in an archive template and that template is used on the pages "Wikipedia talk:Foo/Archive 1" and "Wikipedia talk:Foo/Bar/Archive 1". Of course, you can use a bunch of if-cases to check how many levels down you are and then return the lowest level, but that is a a lot of tricky coding. And in some cases you can't use {{SUBPAGENAME}}, since it doesn't work in all namespaces. While {{pgn|subpage}} works in all namespaces.

And titleparts can't give you the subjectspace basepagename of the talk page you happen to be on. And if that happens to be in article space, then you also have the pesky problem of the leading colon. But with this template you just do it like this: {{pgn|ss|basepage}}

--David Göthberg (talk) 23:53, 22 April 2009 (UTC)

I'm sorry, David, but that ain't right:

FULLBASEPAGENAME

{{#titleparts:Category talk:Foo/bar/baz/quok|-1}} → Category talk:Foo/bar/baz

SUBJECTFULLBASEPAGENAME

{{SUBJECTPAGENAME:{{#titleparts:Category talk:Foo/bar/baz/quok|-1}}}} → Category:Foo/bar/baz

SUBPAGENAME

{{#titleparts:Category talk:Foo/bar/baz/quok| |-1}} → quok

Negative indices allow exactly the behaviour you say is impossible :P. And it works regardless of namespace (even in namespaces which shouldn't have subpages), which seems to be the idea here. Happy‑melon 09:01, 23 April 2009 (UTC)

Oh, nifty! I didn't know that. (Or perhaps have forgotten about it, I spent a lot of time coding with titleparts last year.) I can perhaps use some of it to simplify the code in this template for some operations.

But that I as an experienced programmer and template coder have problems to wrap my head around titleparts, in spite having used it before, just goes to show how hard it is to use. This template is much more user-friendly.

So lets test your code, right here on this page:

FULLBASEPAGENAME:

+{{NAMESPACE}}:{{BASEPAGENAME}}+

+{{pgn|ns|basepage}}+

+{{#titleparts: {{FULLPAGENAME}} | -1 }}+

+User talk:Davidgothberg+

+User talk:Davidgothberg+

+User talk:Davidgothberg+

Note that {{NAMESPACE}}:{{BASEPAGENAME}} fails in main space (will return a leading colon), and in any namespace that doesn't have the subpage feature enabled.

SUBJECTFULLBASEPAGENAME:

+{{SUBJECTSPACE}}:{{BASEPAGENAME}}+

+{{:User:Davidgothberg/Pgn|ss|basepage}}+

+{{SUBJECTPAGENAME:{{#titleparts: {{FULLPAGENAME}} | -1 }} }}+

+User:Davidgothberg+

+User:Davidgothberg+

+User:Davidgothberg+

Note that {{SUBJECTSPACE}}:{{BASEPAGENAME}} fails in main space (will return a leading colon), and in any namespace that doesn't have the subpage feature enabled (it's the current page that needs to have the subpage feature, not the subject page pointed to).

SUBPAGENAME:

{{SUBPAGENAME}}

{{pgn|subpage}}

{{#titleparts: {{FULLPAGENAME}} | | -1 }}

{{#titleparts: {{PAGENAME}} | | -1 }}

Pgn Pgn Pgn

Pgn

Note that {{SUBPAGENAME}} fails in any namespace that doesn't have the subpage feature enabled.

Am I missing something, or did your methods just fail on the two first cases? (The third one as you can see I could fix by some adjustment.) So your methods are not equivalent to the magic words. Of course, one could argue that one wants another behaviour than the magic words. After all, this page is a top page, so it really doesn't have a basepage. So returning an empty basepage perhaps is logical. Thus your first two cases could be seen as correct. But I think it would be a big step to change the behaviour like that.

And since this page doesn't have a basepage then this page really isn't a subpage. But still, {{SUBPAGE}} mostly means the name of the current page, without the path to it, and that name of this page is "Pgn", not " ". So I think that "subpage" should return "Pgn". (And all three methods did produce that, so all good here.)

And again, using this template is much easier. Note that this template is mostly meant for the archive templates, since they need to work on "Category talk" and "Help talk" pages. But it will also be useful in some cases when you need to point to article names, since it doesn't have the leading colon problem.

--David Göthberg (talk) 12:17, 23 April 2009 (UTC)

No, you're right in that #titleparts doesn't give the desired behaviour on pages that aren't subpages. You're also right to say that this is probably the more logical behaviour. But there's no way the behaviour of {{SUBPAGENAME}} will be changed, and its current behaviour is probably more useful, if slightly illogical. Both the previous examples can be fixed with one wrapping #if statement:

{{#if: {{#titleparts:{{FULLPAGENAME}}|-1}} | {{#titleparts:{{FULLPAGENAME}}|-1}} | {{FULLPAGENAME}} }}

My point with all these snide comments about reinventing the wheel is not that a template to perform these functions is not a good idea, indeed to handle their occasional eccentricities it's useful to have a wrapper function. I'm saying "why aren't you using these simpler methods in the template?"

I also don't think it's necessary or beneficial to combine all the things you're trying to do into one template. They very clearly serve three different purposes, so why not make three templates? If you created a Template:FULLBASEPAGENAME with the logic above, then you could use it whenever you wanted to, and if/when such a function was ever implemented in MediaWiki itself, it could be switched over to simply by converting {{FULLBASEPAGENAME|...}} to {{FULLBASEPAGENAME:...}}. This is what we did with Template:NAMESPACE. Similarly for the others. I think combining them all together in one template is confusing; unless there is going to be a need to select at 'run time' different implementations, which seems unlikely at best. Much simpler to have three template that each do one clearly-defined thing, than one template that uses somewhat confusing syntax to switch between them. IMO, anyway. Happy‑melon 12:47, 23 April 2009 (UTC)

1: I started creating this template 21 hours ago. I am still in the early development and testing phase. When you made your first comment above I had only worked on this template for 5 hours.

2: Your code example seems to be the FULLBASEPAGENAME case. For that case, then your code might be simpler, if it is in a separate template. Since my code has to handle the namespace part first. Or maybe not, since here is how I could code the FULLBASEPAGENAME case, if in a separate template:

{{#if:{{NAMESPACE}}| {{NAMESPACE}}: }}{{BASEPAGENAME:Template:{{PAGENAME}}}}

If we would use your method to make a BASEPAGENAME function that works in all namespaces, then this would be the code, right?

{{#if: {{#titleparts:{{PAGENAME}}|-1}} | {{#titleparts:{{PAGENAME}}|-1}} | {{PAGENAME}} }}

I don't find that simpler than my code:

{{BASEPAGENAME:Template:{{PAGENAME}}}}

3: I don't want to split this into several templates, since it wouldn't be three templates like you think, it would be five templates just to cover the basic cases that we need the most:

• {{pgn|basepage}} = {{basepagename}}
• {{pgn|ns|basepage}} = {{fullbasepagename}}
• {{pgn|ss|basepage}} = {{subjectbasepagename}}
• {{pgn|ts|basepage}} = {{talkbasepagename}}
• {{pgn|subpage}} = {{subpagename}}

I used lowercase for your templates, to avoid name collisions with the already existing magic words {{BASEPAGENAME}} and {{SUBPAGENAME}}. And as I said before, we can't use those magic words since they don't work in all talk spaces. So we wouldn't want those templates to be superseded by any new magic words. Since if they make new magic words, they will not work in namespaces that don't have the subpage feature enabled.

I find my notation simpler to remember and spell. And I think it makes it easier to read in code when we use several of the cases at the same time. And I find it simpler to document my solution.

If it is several templates then we who use them can't trust that they are fully compatible with each other. Experience has taught us that people will tweak them, so they might become slightly incompatible. So as a user of the functions I would have to carefully test each of them to see what they do. But if it all is in one template then I can trust better that the different functions behave in the same way.

4: With the {{pgn}} template we can have all functions in one easy to remember place. For instance, some programmers prefer to work with relative path notation, such as [[../sibbling]]. But that of course doesn't work in "Category talk" etc. And what name would you give a separate template for that functionality? But I have already added and tested that notation in the /sandbox version of {{pgn}}. And it works in all namespaces. It looks like this:

{{pgn|..|sibbling}}

{{pgn|..|..|uncle}}

Nifty, isn't it? And I have more things coming.

--David Göthberg (talk) 15:00, 23 April 2009 (UTC)

I'm not trying to demean your efforts or say that it's not a useful thing to do; I saw your edit to your userpage, wondered what the template did, had a look, and saw a way I thought you could improve it. I agree that, in fact, #titleparts is not universally better than the methods you're currently using, but it is simpler in some cases.

I strongly disagree that the syntax in {{pgn}} is at all simple. The syntactic meaning of the second parameter varies depending on whether or not there's a third parameter! If you do implement the relative paths from the sandbox it gets even worse, as the syntactic meaning of the third parameter itself becomes variable. As opposed to separate templates that each take one optional parameter, and do one thing with it that's intuitive from the template name. Full relative path notation doesn't work anywhere else in MediaWiki (except the #rel2abs function); what is the benefit from enabling it in this one template? Again, I'm not criticising - the code looks clean (as always) and the syntax is ultimately logical - but I see featuritis without any particular reason.

In general we're in full agreement that more templates is an encouragement to 'tweak' them out of alignment, as you say. But how on earth is that possible here? How could you change one of these functions to that it's "not fully compatible" with the others? The different functions aren't supposed to behave the same way :D

I see that there already is a template {{FULLBASEPAGENAME}}, using an inferior method; I've updated it to use #titleparts. I don't see any advantage to having to write {{pgn|ns|basepage}} instead of just {{FULLBASEPAGENAME}}. There's no reason to my mind not to do the same with {{SUBJECTBASEPAGENAME}} and {{TALKBASEPAGENAME}}. The other two are quite simply bugs, and wouldn't be required if we had subpages in the appropriate namespaces. {{pgn}} will fail on pages (File:, Category: and MediaWiki) where we genuinely don't have or want subpages; when subpages are enabled in the extra namespaces, the proper SUBPAGENAME: function won't have that problem, ditto for BASEPAGENAME:. Happy‑melon 15:36, 23 April 2009 (UTC)

Well, we disagree. I think the notation I use is simpler. You think yours is simpler. Different people have different preferences.

What third parameter? There is no third parameter in the documentation. Do you mean the subpage parameter in the code? That's a bug that I have already fixed in the /sandbox. But since I have been busy answering your messages I have not yet had the time to deploy the sandbox version. Besides, this template is still just in development.

Well, someone might find the code in the {{FULLBASEPAGENAME}} template strange, and tweak it. And hey, you just did that, you just changed how that template works. And you didn't even document it. Did you check if there are any related templates? And did you do the same tweak to them too? And that might happen again, since someone might find your titleparts code confusing. Or they might discover the problem that your code currently breaks if fed an empty but defined parameter, so they will rework the template. And then there might come a magic word named {{FULLBASEPAGENAME}}, then someone might simply put that magic word in that template, and suddenly that template doesn't work in the "Category talk", "Help talk" and "Help" namespaces.

What do you mean by "full relative path notation doesn't work anywhere else in MediaWiki"? Do you mean that using several ".." in a row doesn't work? But it does. Try this [[../../C2]] on User:Example/B/C/D.

Or did you mean that relative path notation only works in links? Well, yes that is true. But since such links currently don't work in "Category talk", "Help talk" and "Help", we could have use of a template that can help us build such links. I usually don't use "../.." notation myself. But from what I remember there are some cases when archive templates need to go two levels up, and that can't be easily done with the "basepage" keyword.

I wouldn't call it "fail" when the template gives a subpage name when on a "Category:" page. If a template needs to handle subpages, then it should be allowed to do it, no matter where it is placed. Instead of as now when the magic words simply return something that I consider junk data, since that data causes more problems than returning properly formatted subpage data. Besides, since when are we placing archive templates etc. on "Category:" pages? (But we do place them on "Category talk:" pages.) And there are as you know many legitimate needs to be able to handle subpages in the "Help:" namespace, even though that namespace has the subpage feature disabled.

"When subpages are enabled in the extra namespaces" Well, they aren't enabled now, and there's no telling when they will be enabled. It might take days, or it might take years, or our sysadmins might never enable them. I want to fix the archive templates this month, not 5 years from now.

--David Göthberg (talk) 17:13, 23 April 2009 (UTC)

Indeed they do, and of course there's no reason why both methods can't coexist. Although then you have the much more likely situation of their functionality diverging. It would probably be preferable to have one solution, but who's to say which? We could get some more input but... realistically, we built at least half the templates in Category:Wikipedia metatemplates... I seriously doubt anyone else gives a damn!!

Actually I did do all of those things. {{FULLBASEPAGENAME}} has no tranclusions in mainspace, which is where any change would be manifest. There is only the similar template {{ROOTPAGENAME}}, which already had the #titleparts fix in place. I would be glad for anyone that did come around and investigated how the template worked; if (as has been the case, thanks Amalthea!) it transpires that the code can be further improved, I'd be equally glad if that were done. Thanks also to Amalthea for writing the docs for both pages just now.

I admit that I didn't know whether full relative paths (ie more than just /subpage) worked in links when I read your comment. I immediately tested it in Special:ExpandTemplates, where it fails (gives a nowikied link); hence my comment. That's a bug, since you're quite right it works for both internal links and transclusions on normal pages; I just filed that ({{bug18567}}). It's still very variable, however; it doesn't work in #ifexist, in magic words like {{PAGENAME:../sibling}}, or (bizarrely enough) on interwiki links like [[meta:../sibling]]. It seems like a very buggy feature to me. Again #titleparts could handle such; the code is just like FULLBASEPAGENAME but with a -2 instead of -1.

I think I would consider it unexpected behaviour for a template to indicate that subpages existed in Category:, File: or MediaWiki:; that's a completely different situation to using templates to compensate for slow action on the part of the devs to fix the subpages issue in Category talk:, Help: and Help talk:. As you say, however, since such templates are unlikely to be used in those namespaces, the problem is not significant. What is really needed, of course, is for there to be subpages in those three namespaces. Happy‑melon 18:40, 23 April 2009 (UTC)

I wrote this message back in April 23, but hesitated to post it so I just saved it locally on my hard disk. Instead I went on a wikibreak to think things over. But here goes:

Understand that you don't understand these things. I created this template since I have a number of usage cases where I need it. Some, but not all, of those cases concerns the archive template system. You don't know those cases so you don't know what needs there are. I refuse to spend time writing 5-10 pages of examples, explanations and motivations before I start coding and testing a template.

One solution? I don't consider your approach to be "one solution", since it means a whole bunch of different templates. And your "solution" doesn't solve all the usage cases where I need this template.

Relative paths work fine in Special:ExpandTemplates, you just have to set a "Context title" like "Template:A/B/C/D" so the relative path has something to work with. If it fails since you use invalid input, then it shows as plain text.

Relative paths only work in links, it is part of the link syntax. So #ifexist of course can't use it, since ifexist doesn't use [[links]], it uses plain text pagenames. And of course it doesn't work on interwiki links, since what should the relative path be relative to? A relative path only works relative to the current page, nothing else. And there is more to interwiki links than you might think. So again, understand that you don't understand these things.

And could you keep out of the way? This is silly, this template is in the early experimental and development phase, it isn't even close to finished. It's just a couple of hours old. I shouldn't have to defend an early experimental version. Instead of developing this template I have spent most of the day defending my development code. And yes, most of the day. Since English isn't my native tongue it takes me a lot of time to write responses. You are wasting my time, and you are making me want to leave Wikipedia.

So please, I don't want any response from you, I don't want any faulty advice, I don't even want any questions from you. I just want to be able to do my work here.

I don't want to go back to what I did in the old days: Develop my templates in secret pages in my user space, without any links to them from anywhere. So people wouldn't deploy them before they were ready, so I wouldn't have to answer a zillion questions about them since their documentation wasn't ready, and so admins wouldn't delete them "since doesn't work" or so admins wouldn't protect them before I had finished them. And even that didn't always help, since some people checked my user contributions and found my user-space test-pages. There have been cases when admins blanked pages in my user space, since they didn't like (didn't understand) the templates I was developing there. At some points in time I considered getting a secret account that I would only use for template development in that account's user space. But I decided that if it would go that far, then I'd better leave Wikipedia instead.

--David Göthberg (talk) 10:51, 21 May 2009 (UTC)

I don't know whether you stand by your comment "I don't want any response from you"; I guess the fact that you posted this suggests not. Whichever, that is the one part of your comment I must disregard, because it demands a response. Because the situation, the idea that I may be in some part responsible for driving you away from the project, actually makes me slightly sick.

Let there be no dispute: you are an infinitely better coder than I am. I am sloppy, I make mistakes, I don't check things as thoroughly as I could, and should, before deploying them. I rely on bug reports and hope that a dynamic and rapid response to fixing bugs when they're noticed makes up for allowing them to creep in in the first place. On the other hand, I don't think I've ever seen you make a mistake on live code. When we work together (often more along the lines of me saying something that prompts you to come up with yet another amazing, and reliable, idea, than me actually doing half the work), the results are, I think without exception, impressive. The results when you work alone are equally impressive: reliable, simple templates that do what they say on the tin. When I work alone... well, that doesn't usually apply, because you often can't separate my work from the people who help me polish up whatever it was I was working on. It ends up better than it started, but entirely as a team effort.

So of all the comments in your post, the one that saddens me the most is that you thought you had to "defend" your work to me. Coming back to this discussion after so long, I can read and see where that perception came from. But please believe, from the bottom of my heart, that that is not what I was trying to do. All I wanted, was to point out features, #titleparts initially, later improvements to core parser functions, which I thought would be useful. You're right that I don't know why you needed this template, or what it needed to do. It would have been madness for me to discourage you from doing what you do best: build templates that work, all the time.

In the end, we were looking at this problem from two different sides. As someone looking to become a developer, I saw a problem that should be being fixed in MediaWiki core, and these templates as workarounds until that functionality is made available. My implementation was therefore geared towards being easily replaced by core software. You saw the need for a template to do X, so you can work more magic downstream. To have had such a clash over this was crazy; they're not even mutually exclusive: if the core functionality is fixed, it can be used to simplify this template. I stand by that position: this functionality should be available in core, and I hope it will sooner rather than later. I stand by my suggestion of #titleparts: it is useful in this circumstance, as you agreed. I am deeply saddened that we fell so far from seeing eye-to-eye over its implementation.

I read your comment on your talk page, and your last paragraph here. It's depressingly similar to what you wrote over a year ago. I remember reading that when I was writing my RfA nom, and sympathising fully. Although I ended up making light of it, I did hope that by nominating you for admin, I could help prevent such issues being repeated. So to find myself responsible for creating such a situation, that sickens me. I'm upset, naturally, that you've called me a fool, but if that's your feeling, then it's well deserved, because there is nothing I could do more damaging to this project than to drive you away from it. So if I have, however inadvertantly, then please, accept my apology for it, from the bottom of my heart. Happy‑melon 14:43, 21 May 2009 (UTC)
Wow, I can't believe I've taken three hours to write one post...

Age of the template

May I assume the template is old enough to remove David's (8-month old) notice about how new it is? --NYKevin @978, i.e. 22:27, 9 August 2010 (UTC)