Template talk:PAGENAMEBASE

(modifications shown below. commented sections and tabulation altered in order to convey the function more clearly. red = removal, green = addition)

{{#ifexpr:
  {{str find
  {{strfind short
     |{{PAGENAME}}
     |(
     |1
     |lenstr={{strlen quick|{{PAGENAME}}}}
  }} != -10 <!-- IF PAGENAME CONTAINS OPENING PARENTHESIS -->
  | {{str ≤ len <!--THEN CHECK TO SEE IF THE PAGENAME IS LESS THAN 98 CHARACTERS -->
     | {{PAGENAME}}
     | 49 <!-- The max {{str find}} can handle is 50 -->
     | 69 <!-- The max {{strlen quick}} can handle is 70 -->
     | {{str left <!--IF SO THEN RETURN ALL TEXT TO LEFT OF OPENING PARENTHESIS-->
          | {{PAGENAME}}
          | {{#expr:
              {{str find
              {{strfind short
                 |{{PAGENAME}}
                 |(
                 |1
                 |lenstr={{strlen quick|{{PAGENAME}}}}
              }}-2
           }}
        }}
     | {{PAGENAME}}<!--ELSE RETURN FULL PAGENAME-->
  }}
  | {{PAGENAME}} <!--ELSE RETURN FULL PAGENAME-->
}}<noinclude>
{{documentation}}
<!-- Add categories and interwikis to the /doc subpage, not here! -->
</noinclude>

The function of this template will be altered as follows:

Original function:

If the pagename has an opening parenthesis at or prior to index 49, return all text preceding the opening parenthesis.

New function:

If the pagename has an opening parenthesis at or prior to index 98, return all text preceding the opening parenthesis.

Additional changes:

The replacement of {{str find}} with {{strfind short}} should reduce (several times over) the time and resources required to return the base of the page name and will allow for this template to work for titles ranging up to 99 70 characters long. It currently only supports titles with 50 or fewer characters.

Bob the WikipediaN ^{(talk • contribs)} 02:43, 5 February 2011 (UTC)[reply]

If there's better performance both computationally and in the range of inputs that can be handled, then this looks like a WP:SNOWBALL to me. Do test it in the sandbox, though - I've just amended the code based on a slight difference in return value. Martin (Smith609 – Talk) 16:52, 5 February 2011 (UTC)[reply]

Thanks for observing that mistake and correcting it. As soon as I finish checking email and discussions I'm involved in, as well as the mid-edit state I left Grallator in last night, I'll set this up in my sandbox as a test model and post back here once I've done so. Bob the WikipediaN ^{(talk • contribs)} 18:17, 5 February 2011 (UTC)[reply]

Affected templates:

• {{Taxobox}} (Test version available at User:Bob the Wikipedian/Taxobox)
• {{Automatic taxobox}} (Test version available at User:Bob the Wikipedian/Automatic taxobox)
• {{Ichnobox}} (Test version available at User:Bob the Wikipedian/Ichnobox)
• {{Oobox}} (Test version available at User:Bob the Wikipedian/Oobox)
• {{Speciesbox}} (Test version available at User:Bob the Wikipedian/Speciesbox)
• {{Taxobox name}} (Test version available at User:Bob the Wikipedian/Taxobox name)
• {{Taxobox/taxon}} (Test version available at User:Bob the Wikipedian/Taxobox/taxon)
• {{Subspeciesbox}} (Test version available at User:Bob the Wikipedian/Subspeciesbox)

Because {{Subspeciesbox}} is using {{BASEPAGENAME}} (should it be using {{PAGENAMEBASE}} instead?), it will be unaffected. (fixed, Martin (Smith609 – Talk))

This template is designed to return the name of the page excluding anything before the parentheses. It's currently used in the taxobox title, the calculation of the taxon when |taxon= is empty, and the calculation of the daughter taxa when |taxon= is empty.

Please report any bugs on this page.

Happy testing! Bob the WikipediaN ^{(talk • contribs)} 02:33, 6 February 2011 (UTC)[reply]

Note-- testing this in a sandbox won't do anything; you'll need to actually test it using the preview changes button in actual articles. The reason is because the PAGENAMEBASE grabs the title of the page. Bob the WikipediaN ^{(talk • contribs)} 02:36, 6 February 2011 (UTC)[reply]

Or, you can test using Special:ExpandTemplates. Martin (Smith609 – Talk) 13:28, 6 February 2011 (UTC)[reply]

Subspeciesbox can now be tested; I've provided the sandbox version above. I've also corrected case-sensitive typoes in the oobox and ichnobox. Bob the WikipediaN ^{(talk • contribs)} 19:01, 6 February 2011 (UTC)[reply]

I've discovered that in order for longer strings to work, the |lenstr= must be used. However, {{strlen quick}} supports only 70 characters, so 70 would be the new cutoff instead of 99 (this is still 20 more characters than before). Bob the WikipediaN ^{(talk • contribs)} 19:46, 6 February 2011 (UTC)[reply]

It's a long binomen indeed that runs to 70 characters. As far as I know the limit of 50 has never caused problems; so I'm sure that this'll be fine, and hopefully we'll feel the performance improvement. Out of interest, do you have any metric on the size of the potential performance gain? Martin (Smith609 – Talk) 03:08, 7 February 2011 (UTC)[reply]

I don't have the appropriate tools to measure metrics (or if I do, they've yet to be pointed out to me), but here's some performance reassurance from Wikid:

The template was designed to use only 5 levels of expansion depth, rather than 18 or more levels as in other string-searching templates.... The operation of Template:Strfind_short was designed to run 4x times faster than other string-search templates; however, it typically runs 20x times faster (or shorter) for strings up to 15 characters long. The post-expand include size averages about 300 bytes (rather than 6,000 bytes for other string-search templates). It can be used over 5,000 times per page (compared to only 350 times for other search templates). For strings over 50 long, it will use more resources, due to processing strings larger than what other templates had allowed.

The Template:Strlen_quick ... was designed to run quickly and use only 5 levels of expansion depth, rather than 9-13 or more levels as in other string-length templates.

Any idea where I can find the tools I need to do some tests that would answer your questions? Bob the WikipediaN ^{(talk • contribs)} 05:24, 7 February 2011 (UTC)[reply]

• Changing the template to use parameter 1 as the title would make testing the performance easier, to allow setting the title, else default to {PAGENAME}: {{{1|{{PAGENAME}}}}}. I'll mention more about measuring performance, later. Anyway, thanks for clarifying the markup used in the template, so I have created another string utility template to optimize getting the title prefix. See below: "#Proposal for shorter, faster version". -Wikid77 14:58, 7 February 2011 (UTC)[reply]

The Template:PAGENAMEBASE could be optimized, even further, to expect most titles to have "(xx)" and search for "(" only once. Although, in the mix of article titles, the parentheses "(xx)" are only about 23% of articles, the template could be changed to optimize handling of all titles. The new Template:Strloc_prefix can be used to check for "(" or get the entire title, as one step, rather than multiple if-logic. The optimized markup for Template:PAGENAMEBASE is simply:

{{Strloc prefix|{{{1|{{PAGENAME}}}}}|
   strloc= {{strfind_short|{{{1|{{PAGENAME}}}}}|(|1|
     lenstr= {{strlen_quick|{{{1|{{PAGENAME}}}}}|}}}}-2
}}

That would be the entire new contents of Template:PAGENAMEBASE, due to the condensed logic of checking the result of strloc within Strloc_prefix. The result would be over 2x times as fast as merely inserting {Strfind_short} into the existing version of {PAGENAMEBASE}. All the prior checking for string lengths of 49 long (and such) would be unnecessary, because regardless of string length, when a "(" is not found, the entire title is considered the result. Hence, there is no reason to check for 49 (or 69), because that check is a logical tautology: if within 49 or over 49, the lack of "(" always returns the entire title. Either way, same result; hence, don't check the length. By setting strloc={{strfind_short|...}}, the search for "(" occurs only once, outside the if-logic, also allowing the template to have a smaller "expansion depth": the markup expands 5 deep into {strfind_short}, then comes back up with the result as strloc, then descends 2 deep into {strloc_prefix}. That organization allows Template:PAGENAMEBASE to have a shorter expansion depth, and allows it to be used at the lowest levels inside deeply-nested taxonomy templates. Gotta run now. Thanks again for clarifying the issues. More later. -Wikid77 14:58, 7 February 2011 (UTC)[reply]

Thanks for that, and shame on me for not summoning you here-- glad you found it. Since there are relatively fewer titles with parentheses in the organismal realm, I'm not sure it's wise to use a template that expects parentheses. But have I misinterpreted your proposal? Bob the WikipediaN ^{(talk • contribs)} 15:35, 7 February 2011 (UTC)[reply]

• By the word "expect" I mean that it must always handle the parentheses, if present, so optimize to handle them, in the mix of all titles. For example, if a title were of the form "x(123)" then I would expect {PAGENAMEBASE} to just give the whole "x(123)" when there is no space is before the left parenthesis "(". Currently, {PAGENAMEBASE} gives nothing when a title is "x(123)" or similar, so the shorter "optimized version" is also a fix to handle all titles, even "x(0)" or such. Wikid77 18:09, 7 February 2011 (UTC)[reply]

But what happens if you throw in a title without parentheses? I'm not sure we're understanding each other here. Bob the WikipediaN ^{(talk • contribs)} 02:45, 8 February 2011 (UTC) Comment retracted at 02:49, 8 February 2011 (UTC) by Bob the WikipediaN ^{(talk • contribs)} [reply]

Ah, I see what's going on now. Looks like a wise proposal. Bob the WikipediaN ^{(talk • contribs)} 02:49, 8 February 2011 (UTC)[reply]

Changed per Wikid's proposal. Bob the WikipediaN ^{(talk • contribs)} 01:13, 13 February 2011 (UTC)[reply]

If the {{{1}}} paranmeter was added back as in the sandbox then this template and Template:Title without disambig could be merged into one. Thoughts? -- WOSlinker (talk) 07:36, 18 November 2014 (UTC)[reply]

seems like a good idea, and would also facilitate testing. Frietjes (talk) 18:04, 18 November 2014 (UTC)[reply]

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

The current version of this template does not support substitution. When using {{subst:PAGENAMEBASE}} the results are displayed as expected (the current PAGENAME minus any disambiguation), but are saved as:

{{#Invoke:String|replace|{{PAGENAME}}|%s%(.*%)||plain=false}}

I have implemented a fix using safesubst: at Template:PAGENAMEBASE/sandbox and tested it at Template:PAGENAMEBASE/testcases to ensure that it works without affecting the current usage (both with and without the recently added parameter 1). I'd appreciate it if an admin would update this template with the sandbox code (I have template editor rights, but this page is currently protected so that only administrators can edit it). Thanks. Zyxw (talk) 05:09, 2 December 2014 (UTC)[reply]

Done I've used a more accurate pattern to detect ending parentheses as well. And I've reduced the protection level to template-protection for next time. — Mr. Stradivarius ^{♪ talk ♪} 07:01, 2 December 2014 (UTC)[reply]

Appreciate the quick turnaround plus your additional work on this. Thanks. -- Zyxw (talk) 07:47, 2 December 2014 (UTC)[reply]

@Mr. Stradivarius and Zyxw: an interesting quirk of using {{{|safesubst:}}} instead of <includeonly>safesubst:</includeonly> is that {{PAGENAMEBASE|=garbage}} does something somewhat unexpected. Frietjes (talk) 16:43, 2 December 2014 (UTC)[reply]

@Frietjes: I just wanted {{subst:PAGENAMEBASE}} to work as expected. If <includeonly>safesubst:</includeonly> is a better solution than {{{|safesubst:}}}, please go ahead and update the template. I read about both methods at Help:Substitution#Recursive substitution, but that didn't have much about why one would be preferred over the other. I only chose the empty parameter method because I noticed it more often when reviewing other templates which use safesubst:. Thanks. -- Zyxw (talk) 03:15, 3 December 2014 (UTC)[reply]

Wouldn't this template work more effectively written in Lua? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:36, 8 December 2014 (UTC)[reply]

It's mainly Lua already. The only bit that isn't is the PAGENAME bit. -- WOSlinker (talk) 18:34, 8 December 2014 (UTC)[reply]

This template is not functioning well with asterisks.

Some text {{PAGENAMEBASE|**Title with asterisk (disambiguation)}} some more text

gives:

Some text

• • Title with asterisk some more text

It should be:

Some text **Title with asterisk some more text

This can potential cause problems with pages with title begins with asterisks (like *** (novel) and * (disambiguation)), considering this (PAGENAMEBASE) is a string handling template that is often used in other templates. Tran Xuan Hoa (talk) 20:19, 3 November 2015 (UTC)[reply]

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

The current version does not support mutiple parentheses well. An example: {{PAGENAMEBASE|Stadion der Freundschaft (Frankfurt (Oder))}} is shown like this: "Stadion der Freundschaft (Frankfurt" instead of like this: "Stadion der Freundschaft". A possible solution is to change |%s+%([^%(]-%)$||plain=false}} to |%s+%b()$||1|false}}. (This change was done a month ago on the Swedish Wikipedia and works fine.) Svensson1 (talk) 12:00, 5 March 2016 (UTC)[reply]

Not done for now: Svensson1, I've added your code to the sandbox and your example to the testcases and the result omits all parenthesised text where parentheses are nested. I'd rather solicit opinions (consensus) and alternatives before rushing ahead with this resolution to the problem. Bazj (talk) 12:32, 5 March 2016 (UTC)[reply]

Note: The documentation states:

• (original version) Returns the {{PAGENAME}} with any bracketed term removed.
• (current version) This template returns the current {{PAGENAME}} minus any disambiguation (text in parentheses).

The implementation seems to have diverged from this documented behaviour at some point along the way.

Pinging previous contributors in the hope of enlightenment... Mr. Stradivarius, WOSlinker, Dragons flight, Bob the Wikipedian, Smith609 Bazj (talk) 13:24, 5 March 2016 (UTC)[reply]

@Svensson1 and Bazj: I've added some more tests to the test cases page. The proposed change alters the template's behaviour with unmatched parentheses (see the last test case), but I think we are more likely to have nested parentheses than unmatched parentheses in titles, and now we know that we have at least one title with nested parentheses. The proposed change looks like an improvement to me. — Mr. Stradivarius ^{♪ talk ♪} 15:50, 5 March 2016 (UTC)[reply]

Mr. Stradivarius, How about |%s%(.*$ which chops from the first open parenthesis & is in the current sandbox version? Bazj (talk) 16:46, 5 March 2016 (UTC)[reply]

Your suggestion to maybe cut the page name "A (b) (c)" to "A" instead of "A (b)" is a rather big change from how this template works for the moment (but maybe it doesn't exist so many page names that looks like that). A small clarification concerning the part %b() in the expression that I proposed: It is a special regular expression symbol which purpose is to match/balance left and right parentheses. Svensson1 (talk) 20:47, 5 March 2016 (UTC)[reply]

Yes, we should only remove the final parentheses. We actually do have titles that rely on this behaviour, for example Sweet Dreams (Are Made of This) (album). — Mr. Stradivarius ^{♪ talk ♪} 03:41, 6 March 2016 (UTC)[reply]

Sweet Dreams (Are Made of This) (album) brings its own counter-example, the single Sweet Dreams (Are Made of This). It's unfortunate that the documentation and the implementation have diverged from the original with an impossible promise that disambiguation will be removed when, as you point out, we have no way of knowing what lies within the brackets.

However, based on...

• the principle that we shouldn't break stuff - which compels us to perpetuate the current behaviour despite its erroneous assumption that the final set of brackets always contain disambiguation and other brackets don't,
• the reasonable assumption implicit in the suggested code that articles with mismatched brackets are soon renamed to a version with balanced brackets,

Svensson1's code seems the best way forward.

Svensson1, thanks for bearing with it while we explored the issues around the request. I'll update the documentation so that it reflects actual behaviour, not a fantasy version of what ought to happen in an ideal world.

Done Bazj (talk) 09:43, 6 March 2016 (UTC)[reply]

Is there a version of this template that would (also) strip text after a comma? It would be useful for articles like cities, where the disambiguation is done by a comma before the containing country. — HTGS (talk) 00:49, 29 May 2023 (UTC)[reply]