Jump to content

Template talk:In title

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
(Redirected from Template talk:Intitle/doc)
[edit]

I think it would be appropriate (and more elegant) to hide the external link icon by applying <span class="plainlinks"> to this template.

Also, analogous to {{Lookfrom}}, I think the right category for this template is Category:Internal link templates instead of Category:Link templates. -- Michael Bednarek (talk) 08:56, 2 November 2008 (UTC)[reply]

Agreed, and done.--Kotniski (talk) 09:50, 2 November 2008 (UTC)[reply]

Forced quotes

[edit]

This recent edit made the code much better. However, I'm not sure the embedded quotes around the argument are necessary. They force a verbatim search for the argument, where, as I understand it, the old code did not. Compare the results of

It seems the new code changes the template's functionality. If users want the exact string search, they can add the quotes. I suggest to remove the quotes from the code.

[[Special:Search/intitle:{{{1|{{PAGENAME}}}}}|All pages with titles containing {{{1|{{PAGENAME}}}}}]]

If a visual distinction is felt necessary, maybe the text part could be distinguished with {{Xt}} or something like it:

[[Special:Search/intitle:{{{1|{{PAGENAME}}}}}|All pages with titles containing {{Xt|{{{1|{{PAGENAME}}}}}}}]]

Then again, may be a colon (:) before the search term is sufficient (… containing: foo). -- Michael Bednarek (talk) 14:14, 23 September 2009 (UTC) (2¢)[reply]

What is the template used for?

[edit]

I've seen it on a DAB page (Charles Eliot), but only on one. WLU (t) (c) Wikipedia's rules:simple/complex 12:04, 22 May 2011 (UTC)[reply]

See Wikipedia:Manual of Style (disambiguation pages)#"See also" section. It's compromise method for enabling readers to find titles containing the ambiguous term without cluttering the disambiguation page with unambiguous partial title matches. older ≠ wiser 12:33, 22 May 2011 (UTC)[reply]
It does the same as the search box, and as such it is cluttering the page, quite the opposite of avoiding it! Also it is patronising the readers: who can't use a search box? Of the few that can't, who shouldn't learn how to? - Nabla (talk) 02:08, 28 August 2011 (UTC)[reply]
Yes, it is similar to the search function. But it does serve a useful purpose on disambiguation pages. Your suggestion that users should either learn how to use the search box or give up is unhelpful. older ≠ wiser 02:21, 28 August 2011 (UTC)[reply]
It doesn't do the same as the search box (unless you happen to know about the "intitle" search keyword, which most users won't; and it's a hassle to type even if you do).--Kotniski (talk) 09:55, 28 August 2011 (UTC)[reply]
Users cant't learn how to use the search box?! Write what you are looking for, hit enter? How hard can that be? The result may not be exactly the same as with some keyword but it is close enough. It is an hassle to write "intitle"? No (further) comments... It looks to me like you are cluttering pages and patronising users for only a marginal gain if any at all. But maybe I am wrong... Can anyone find any stats about how hard is it to use search boxes (in general and in WP)? - Nabla (talk) 17:12, 28 August 2011 (UTC)[reply]
The links are hardly obtrusive by any measure and your expert familiarity with Wikipedia interface is not the appropriate standard by which to gauge expectations for novice readers. Consider that a reader may have entered a term into the search box and arrived at a disambiguation page (or perhaps at a primary topic with a hatnote to the disambiguation page) and they don't find what they're looking for on the disambiguation page. Now you think it is perfectly obvious to enter the same term into the search box and expect to get a different result -- I suspect that many novice readers are not so attentive to the wiki UI to realize that there's also an option in search to select "containing X" which would give a different result than simply entering the term and pressing enter -- I know I never realized it until quite recently after other editors were discussing it -- and I had been using the search function for years. Further, the links in see also are appropriately positioned for a reader to select if they have completed scanning the page and didn't find what they expected. Your suggestion involves scrolling back to the top of the page (at least in the default Vector skin) to do another search. older ≠ wiser 19:09, 28 August 2011 (UTC)[reply]
Yes, and there's also the point that the "intitle" search (which this template provides) specifically searches in article titles, whereas the standard search (even if you manage to find it in the new interface) searches article text. It's not the same thing.--Kotniski (talk) 19:14, 28 August 2011 (UTC)[reply]

Could we have a version which searches redirects too?

[edit]

Creating the dab page for Aquilo I added a {{In title}} link as a "See also", but was disappointed to find that it didn't pick up the three or more redirects with the word, such as Notomys aquilo (I removed the "In title" link, as it didn't offer anything not already in the dab page). {{Look from}} does include redirects in its A-Z listing, italicising them, and this is helpful. Could someone perhaps write a variant of {{In title}}, or add a parameter to this one, to allow searches to find titles of redirects? It seems a useful extension of its function. Any thoughts? PamD 16:43, 18 June 2014 (UTC)[reply]

This template simply invokes the Wikimedia search [[Special:Search/intitle:Aquilo]]; which namespaces are searched depends on the user's remembered preferences at the Advanced Search screen, but there doesn't seem to be any way to return the title of REDIRECTs with this construct. Maybe this should be discussed at Help talk:Searching. -- Michael Bednarek (talk) 03:41, 19 June 2014 (UTC)[reply]

New search syntax

[edit]

Per MediaWiki Help:CirrusSearch,

  • intitle:"foo bar"
Finds articles whose titles contain foo and bar.
  • intitle:foo bar
Finds articles whose titles contain foo and whose title or text contain bar. (emphasis added)

Should this template language be updated? Hoof Hearted (talk) 20:35, 18 March 2015 (UTC)[reply]

OR malfunctioning?

[edit]

Try the example from the template documentation: {{in title|Wales OR Welsh|Article titles containing the words "Wales" or "Welsh".}} Article titles containing the words "Wales" or "Welsh".

Then try {{in title|Welsh OR Wales|Article titles containing the words "Welsh" or "Wales".}} Article titles containing the words "Welsh" or "Wales".

The first produces the "Wales" list, the second the "Welsh" list.

I'm sure this template and its "OR" logic used to work OK. Am I missing a trick, is the documentation out of date, or is the template broken? PamD 14:26, 28 November 2015 (UTC)[reply]

(I took the liberty of adjusting your text to reflect your intent.) Help:Searching says: "'intitle: speed OR velocity' also works"; it seems it no longer does. I can't find any documentation on Wikipedia on how to make intitle: and OR work, but I note that Special:Search/Wales OR Welsh still works. -- Michael Bednarek (talk) 02:25, 29 November 2015 (UTC)[reply]
Thanks. "Special:Search" would pick up all articles with the words anywhere in text, not what I'm really looking for, but would be better than nothing. I've raised the question at the village pump in case anyone can shed light on it. There are probably a shedload of dab pages which have an "OR" statement in a {{in title}} link in their "See also" section, now presumably not working! PamD 13:45, 30 November 2015 (UTC)[reply]
And a quick experiment with {{Special:Search/indicus OR indica OR indicum}} produces a whole lot of "hits" like Dusky smooth-hound where "Smallbelly catshark (A. indicus)" is in the enormous navbox template, a real red herring (mixing my marine life here). PamD 16:10, 30 November 2015 (UTC)[reply]
OR works, just not with certain parameters, like intitle. The template {{in title}} is just a search link whose search is intitle, and whose display text is output in HTML tags that will disappear that text for the printed page. — CpiralCpiral 03:15, 16 December 2015 (UTC)[reply]
OR used to work with this template; now it doesn't. Removing it from he documentation was a crude attempt of hiding the problem. I suspect there are many uses of this template which use "OR" and don't work any more. -- Michael Bednarek (talk) 03:05, 27 December 2015 (UTC)[reply]
Is there anyone watching the page who has any idea what can be done to restore the OR functionality? older ≠ wiser 15:09, 21 October 2016 (UTC)[reply]

All the above questions, again

[edit]

What is this template for? Creating a search link that finds a word or a phrase in titles, and makes the resulting search link into a self-references by classifying the output as "selfreference". (Glance at the simple code). I guess that those should not print, and that we should add the noprint class to this template. One change here and they all get fixed so as not to print or mirror.

Now its been six years, let's see some usage in article space, via search links:

The last one shows 5600 pages where the template is used after a bullet. This will become important below.

Force quotes? Now we have a new search engine that uses quotes almost the same way, and they turn off stemming, so the exact word is found in the title, not stems of the word. Without the quotes, we just get extra pages. Currently I've forced quotes again.

Disambiguation titles? I guess we should rely on the page ranking. It puts words found in the title on top of the search results. Now, although the intitle search parameter (which this template uses) does not search redirect titles, a normal search does. I think we should force quotes and search redirects so we get redirects. Lots of extra pages is the normal "aggressive" search.

The new CirrusSearch intitle does not do OR, and we should not do AND either, but instead use quotes. If the pagename has more than the word or phrase wanted, and if then an OR or AND is wanted, just use a normal {{search link}}.

Then there is the sister template {{look from}} that uses quotes around its term. They are often paired on the dab pages, and look better if they are consistent. We can't make them look consistent if the user puts quotes around the term, hense we simply always force quotes, and say not to bother with them, or else it puts double quotes around the term in the display. The code is very simple here.

So we a have a version in the sandbox. It uses the standard method of creating a search link that will at least accept the search tilde ~ character that forces search results. It uses non-stemmed search and relies on page ranking. So it shows exact phrases, even in redirect pages. It will not show in print. What should we do? — CpiralCpiral 08:57, 17 December 2015 (UTC)[reply]

Just had a go at Village pump (technical) at Should template In title have noprint?, and feel confident about the direction, except for the usage after a bullet. (See counts bullet list) How are we gonna cleanup 5600 bullets? WP:AWB anyone? (5600 easy points) — CpiralCpiral 00:47, 24 December 2015 (UTC)[reply]


I got AWB, and the current sandbox is ready to go, and with {{intitle}} to produce its own bullet automatically unless |bullet= is used. Do people want the default to be to add a bullet like this? — CpiralCpiral 22:52, 26 December 2015 (UTC)[reply]
It's not clear to me what exactly you are proposing, but I suggest much wider input is needed before any changes are made. I think that making any template emit bullets limits its possible use and is not a good idea. -- Michael Bednarek (talk) 03:05, 27 December 2015 (UTC)[reply]
The other option (hypothetically) is to remove the template from article space for 1) violating (guideline) WP:ELNO rule 9, and 2)showing up in print where it makes no sense. The bullet must be in a "noprint div span" emitted by the template, and WP:ELNO must be ameliorated, which I'm partially doing with WP:External links#URL internal links. (See that talk page for more.) I will wait for comments before doing anything. — CpiralCpiral 03:50, 27 December 2015 (UTC)[reply]
I agree with User:PamD and User:Beetstra who pointed out at Wikipedia talk:External links#Disallowing search results pages that you misunderstand #9 at WP:ELNO which applies to external links. I suggest that nothing needs to be done regarding {{In title}} or {{Look from}} (except to fix the lost "OR" capability). -- Michael Bednarek (talk) 04:29, 28 December 2015 (UTC)[reply]
The other need is for a version of {{in title}} which searches titles of redirects as well as articles. PamD 07:05, 28 December 2015 (UTC)[reply]

{{Intitle}} is not Search. Soon {{search link}} (and I) will be available to begin helping to do redirects and ORs. Now I finally understand how and why Search links are allowed in articles. But hardly allowed. Michael, do you agree that having them print out is not allowed? And that either they are fixed or they must be abandoned, which is not an option? They can be fixed. OK? — CpiralCpiral 09:53, 28 December 2015 (UTC)[reply]

They can be fixed, but ... Search link may be available soon, but... maybe not. Please advise us and add to the talk page at WP:NOT. Thanks. — CpiralCpiral 09:29, 31 December 2015 (UTC)[reply]
This template seems to be sanctioned at MOS:DABSEEALSO, but not at WP:NAMELIST (at wp:dab). — CpiralCpiral 03:33, 1 January 2016 (UTC)[reply]

How to alter this template and the wiki

[edit]

This alteration is now cooperating with T123093, where it may happen that there is a possibility of a software change to making an "empty bullet in print" disappear, just as it does in all other "bare bullet" contexts. — CpiralCpiral 18:00, 10 January 2016 (UTC)[reply]

Growth rate

[edit]

The templates behind the "empty bullet in print" problem, grow at over ten per day.

Using the above numbers and the same particular search as above

The wiki

[edit]

{{intitle}} → All pages with titles containing In title

Intitle classifies itself as "selfreference"; "self" being, variously, the article, the encyclopedia, the servers (including the search engine), and the maintainers; together everything that is not the product, (not the an online-encyclopedia); the "reference" being to one of them. Any self reference is to be scrutinized because some of them are "self references to be avoided". It is a simple matter to OK a reference to a section, and to link it. It's also not that difficult to grasp avoiding referencing Wikipedia, once you get that it is not Wikipedia, its an encyclopedia anyone can mirror and call there own (and many do). Where it gets difficult is that other selves avoid different references. The "other" use: the mirror, the fork, the electronic document, and the printed page, they all have there own "self" (or selves).

To simplify the situation, there are only two HTML attributes given by the providers of the software: "selfreference" and "noprint". This leaves mirrors, forks, and ebooks on there own with just the "selfreference" attributes we assign to our HTML spans and divs.

Intitle classifies its output as "selfreference". The neglected self is the "noprint". It should not show up in print. This is a template, so we can add "noprint", and that change will propagate. Let is not repeat the mistake though. There is another self where intitles are used that "do" deserve printing, where intitles are "print worthy", and that is here, in the User namespace, and other places.

Let's dispell the illusion that With the proper label, a search link, appearing normal in black and white print, would not need the selfreference attribute. When the other is a black and white paper the label is printed and the link is black. (Remember, we have a print parameter we can set to on.) But when the other self is an offline electronic document, the producers of those ebooks would, seeing the need to "print" (having no "noprint"), would then be on there own to remove any search link blueness and linkness, while retaining the label for electronic display.

In this case the selfreference tag was not needed. Even where "selfreference" doesn't matter, having it does not get in the way, as we just saw. Then there is no reason to have "selfreference" parameterized (controlled by the end user). The ebook would have not the template (that's wikitext), it would have its HTML permanently substituted, so the ebook producer could use word processing to un-blue-link anything to Wikipedia's personal search engine.[1] To avoid complication, and keep things simple, we always use the self reference when it could be a self reference. Although the label may seem to serve self-determination (whether it is a self reference or not), it's really the template itself.

References

  1. ^ Those search links are all supposed to be deactivated by reusers. Although they may have them, they are not supposed to use them. They are supposed to permanently deactivate the URL. This is one reason, but one built on mistrust, to forbid search links in articles — to avoid misuse of the Wikipedia Search engine by mirrors.

The templates

[edit]

{{Intitle}} and {{lookfrom}} are popular online tools used in over 10000 pp. They are practically sisters.

Intitle is on 2% of dab pages as a bullet item. That's a lot. Intitle is widely used in See also sections as a bulleted item. It is not bulleted (it is inline) where it is used in a hatnote. There are 5–10 new ones added per day.

Old characteristics:

  • showed up in print, or had a negative effect on print
  • used intitle
  • user terms were given as arguments to intitle
  • did not find terms in redirects

New or changed characteristics:

  • To make a noprint bullet we must emit our own bullet in a div class "noprint". A span class "noprint" will not work with a bullet. Any bullet itemized search link, in order to be "not printed", must emit its own "noprint" bullet.
  • To make a noprint inline version, we must emit a span class "noprint".
  • To make a print version, we must add a print parameter.
  • To match in redirect titles, we must not use intitle, but rely on page ranking a simple term search.
  • To do an exact term search (no stemming versions) the template must put the term in double quotes, not the user.
  • We must rely on the end user to place the template in where the page reads well when it is "not printed".

The terms in bold signify what the end user should know. Before it was that redirects did not show. Now its that plus five more things.

{{intitle}}

Defaulting to a div class with |bullet=yes, |print=no, it turns into:

All pages with titles containing In title



(anything before it will appear in print preview) {{intitle}} (anything after it will appear in a print preview)

Defaulting to the same div class as above because it is the default behavior, it turns into

(anything before it will appear in print preview) All pages with titles containing In title (anything after it pops out and will appears in a print preview)



But you can make it inline by changing the default behavior: use the "bullet" parameter.

(anything before it will appear in print preview) {{intitle|bullet=false}} (anything after it will appear in a print preview)

all bullets must be div class, so it turns into

(anything before it will appear in print preview) All pages with titles containing In title (anything after it will appear in a print preview)



We can't redirect a behavioral part of them. We can rename some before the new intitle with the "noprint fix" is swapped into play. we can also parameterize some while renaming them. Together these techniques will avoid any disruption at all, although it will involve a lot of work administering and supervising the bot.


In order to avoid popping the 87 inline ones out of their line:

  1. Create a temporary template {{intitle-inline}}. Done
  2. some text all {{intitle}} in a line → some text all {{intitle-inline}} in a line. As these are renamed, there is no visual change.
  3. Temorarily set the default to |bullet=false, and swap in the new intitle.
  4. AWB the 5590 bulleted ones, changing * {{intitle}} to {{intitle|bullet=true}}. As each one is repaired by removing the print bullet, it will emit the noprint bullet. There would be no visual change, and so no hurry. A generous delay between edits can be used.
  5. Change the intitle default back to |bullet=true. Then we're done.

Step 2 conisists of these 87 to rename to "intitle-inline", probably AWB in manual (not autosave):

Step 4, with a generous 5-second delay between edits (about 7 hr for this) are these:

Those can be automated, because it basically just removes the same bullet and adds the same parameter every time.

Optionally, when all is finished, more AWB bot work:

  1. Rename all the {{intitle-inline}} to {{intitle|bullet=no}}.
  2. Remove the harmless but useless 6000 or so instances of |bullet=true because it is now the default.

— CpiralCpiral 22:50, 26 December 2015 (UTC)[reply]

Your language is a bit unclear and I don't understand what exactly you are proposing, but I suggest much wider input is needed before any changes are made. -- Michael Bednarek (talk) 03:05, 27 December 2015 (UTC)[reply]
Please comment again. The proposal wording and plan was improved, during an edit conflict. Thanks.
I agree there could be wider input on this, and will wait for comments. — CpiralCpiral 03:28, 27 December 2015 (UTC)[reply]
Wouldn't adding Category:Exclude in print be the simplest method if class="noprint" is desired? That would leave the typically used bullet in place, but I think that's a minor nuisance. -- Michael Bednarek (talk) 04:33, 27 December 2015 (UTC)[reply]
A category is metadata. It's div class=noprint> ... </div> that does it. (See Template:In title/sandbox.) I've just added the category to this template, thank you. Yes, the bare bullet left on the print preview is very minor.
Yes the work needed to fix it is horrendous, and may never get done. But that option grows the problem because this template can't be fixed (for the future) without marring the current usage (the past). Besides, this template and {{lookfrom}} are the epitome of why search links have been officially banned from articles (see WP:ELNO rule 9), and if I fix them I sanction a fragile new development that may begin to provide allowance and guidelines for search links (like this one) in article space ipso facto, instead of continuing to forbid them. (See how Template:Search link forbids itself.) I want to help folks improve content by using Search wherever. — CpiralCpiral 06:33, 27 December 2015 (UTC)[reply]
This is an important point, because it means the scale of the work may not be so great! I just... learned something about hastemplate. We only need a hastemplate on the canonical name, but with the regexp matching the redirect too. Ho! its now only a total of 90! P.S. I'll fix all the other search strings right away. Thank you older≠wiser. — CpiralCpiral 10:28, 27 December 2015 (UTC)[reply]
Done re-evaluating and cleaning up the numbers of the proposal (that I've asked many to glance at.) — CpiralCpiral 11:39, 27 December 2015 (UTC)[reply]

Discussion is also available at the bot request: Wikipedia:Bots/Requests for approval/CpiralBot.

Punctuation of search terms?

[edit]

I was about to add {{in title|gold digger}} to the DAB page Gold digger, because I know there are a lot of partial title matches such as Gold Diggers of Broadway and The Gold Diggers' Song (We're in the Money) that are not ambiguous but might be what a user has in mind. However, the resulting "All pages with titles containing gold digger" search doesn't show me those pages. I wondered if the apostrophe in Gold Diggers' Song might have something to do with it, though that might not be what's actually going on. For example, Gold Diggers of 1937 showed up in my search, but not Gold Diggers of Broadway. (Also not showing up, Digger gold nor any title containing just one of those words.) Thoughts? Also, does every search show the same results or might my browser/Wikipedia preferences/who-knows-what be affecting it? Cnilep (talk) 01:23, 5 July 2016 (UTC)[reply]

template:endswith

[edit]

I redirected this here for now but is there a more specific way to do this, not just 'contains' or 'starts with' but when the contain is the end, like searching last names? Ranze (talk) 05:41, 15 August 2016 (UTC)[reply]

That REDIRECT seems misleading, because {{in title}} doesn't do anything suggested by that name. I suggest to request its deletion. Maybe some maven sees this and creates such a template, or this might get a response at WP:VPT. -- Michael Bednarek (talk) 09:43, 15 August 2016 (UTC)[reply]
A template is not needed because Module:String can do pattern searches that can identify if given text ends with something. It would use function find with plain=false, and the target would have "$" at the end to indicate end-of-string. Sorry I don't have time now to say more; as mentioned, WP:VPT would get details. Johnuniq (talk) 11:47, 15 August 2016 (UTC)[reply]

Using quotes automatically in templates

[edit]

I reverted your edit, Cpiral, as possibly an "error". However, I see a good-faith attempt to narrow down the results. However, this has affected a lot of pages there. The consensus is needed. --George Ho (talk) 21:16, 4 January 2017 (UTC)[reply]

intitle takes only one parameter. The way you have it, the "mistake" is that intitle cannot affect the "one" term that is given unless it is in quotes. Have you done these searches with multi-word titles yourself? the second word of the search the user gives is the second word of the title the template programmer gives, is not in the title that the proper searcher's intitle parameter expects; it is in the bodies of the articles presented in the wide search results you claim is best.
I will revert back to my original more conservative search results because I feel there is a strong aesthetic to See Also sections, and because I have just now sampled random articles's titles (via the sidebar tool). Per MOS:DABNOENTRY articles should make intitle results aesthetic. (On the other hand, a search from special:search should be aggressive, but for different reasons.) Since my sample of random articles did not invite an imaginable aesthetic the way you have it, I will revert. — Cpiral§Cpiral 00:13, 1 October 2017 (UTC)[reply]

Italics vs quotation marks (In title vs Look from)

[edit]

{{In title}} displays:

All pages with a title containing Foo

but {{Look from}} displays:

All pages beginning with "Foo"

The former uses italics; the latter quotation marks. I think it would be neater if they were consistent. Could In title be changed to use quotation marks (or the other way round)? Shhhnotsoloud (talk) 07:26, 28 August 2018 (UTC)[reply]

I think this template previously used quotation marks, and I prefer that to be restored. -- Michael Bednarek (talk) 10:46, 28 August 2018 (UTC)[reply]
See this thread for the reasons why I think we should use italics, rather than quotation marks, in both {{In title}} and {{Look from}}. —Ringbang (talk) 16:53, 28 August 2018 (UTC)[reply]
@Ringbang: Yes, {{Look from}} changing to italics would equally achieve consistency, and may be better for the reasons you set out. Shhhnotsoloud (talk) 07:00, 29 August 2018 (UTC)[reply]
In case anyone here didn't see the announcement, both templates use italics now: Galobtter made the change in {{Look from}} on 2 September 2018. Feedback is welcome. —Ringbang (talk) 05:12, 10 September 2018 (UTC)[reply]

Thank you user:Galobtter. Shhhnotsoloud (talk) 07:23, 10 September 2018 (UTC)[reply]

show titles only

[edit]

I'd like a variant of the template {{intitle}} the lists titles briefly in an alphabetical list the way the template {{lookfrom}} works. For example, the search All pages with titles beginning with Alpha is useful, as it lists lots of titles and you can flip from page to page to walk through them. However, the search All pages with titles containing Alpha is not useful in the same way, as the results are not in a simple alphabetic list. Is there a way to do this? If not, I'd like to propose a variant of {{intitle}} that works that way. It is useful to include these at the bottom of disambiguation pages, but the prefix one is more useful. Coastside (talk) 23:43, 26 January 2019 (UTC)[reply]

This is not possible with the MediaWiki software. {{look from|Alpha}} simply produces a link to Special:PrefixIndex/Alpha. Special pages are MediaWiki features. There is no such feature for intitle searches. It would have to be requested as a change to MediaWiki itself. See Wikipedia:Bug reports and feature requests. By the way, some special pages can be "transcluded" (not quite the same as template transclusion). {{Special:PrefixIndex/Alpha-7}} produces the below. PrimeHunter (talk) 01:13, 28 January 2019 (UTC)[reply]

@PrimeHunter: I submitted a feature request with Phabricator. They closed the request with the following comment: 

On-wiki content like user scripts, gadgets, templates, custom CSS are local features and managed independently on each wiki. Phabricator/Maniphest is used for MediaWiki, MediaWiki extensions, or server configuration. In this case you could contact previous authors of local pages (see "View History") or discuss on a corresponding talk page. This is a matter to discuss and fix on the local wiki and not handled in Wikimedia Phabricator until https://phabricator.wikimedia.org/T121470 gets solved, hence closing this task here in Wikimedia Phabricator.
Is there a better way to handle this? Coastside (talk) 16:29, 29 January 2019 (UTC)[reply]
I did a search and found your request at phab:T214810. You should not have mentioned templates but have requested a special page similar to Special:PrefixIndex and Special:PrefixIndex/Alpha, for example called Special:Intitle. If such a special page existed then the template {{intitle}} could use it. Requests for templates don't belong at Phabricator. Requests for special pages do belong there. However, I suspect a proper request would have been declined for other reasons like performance, or would have been left open indefinitely like phab:T12808 ("Introduce Special:Suffixindex") and thousands of other feature requests. PrimeHunter (talk) 16:51, 29 January 2019 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:In_title&oldid=1144177256"