Module talk:Find sources/Archive 1
![]() | This is an archive of past discussions about Module:Find sources. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 |
Broken "news" link

The "news" link hasn't been working for a while. Instead of updating it to match the normal {{find sources}} template, what do you think about scrapping it altogether? The point of this template is the quick link to the RS search, which is included with the {{VG deletion}} delsort template (which also needs to be updated). czar · · 14:41, 22 April 2013 (UTC)
Request for proper capitalization
![]() | This edit request has been answered. Set the |answered= parameter to no to reactivate your request. |
For proper capitalization, could someone please edit Module:Find sources/templates/Find sources to change "highbeam" to "HighBeam" and "wikipedia" to "Wikipedia"? Thanks! GoingBatty (talk) 18:47, 31 January 2016 (UTC)
Is there any reason that Module:Find sources/links/google sets the results per page to 50 instead of the user’s preference (or if it’s by design, why not 100)? Also, can we document the as_eq
parameter with a link to say, this documentation? —LLarson (said & done) 16:33, 5 July 2016 (UTC)
Done Having waited a sufficient amount of time with no objections, I removed the 50-results-per-page parameter from the Google search. —LLarson (said & done) 03:49, 15 February 2019 (UTC)
Regarding the latest revision to this template

Regarding this revision, “‹ The template below (Find sources mainspace) is being considered for merging. See templates for discussion to help reach a consensus. ›” can be seen in the template itself and on pages which use it, such as Ping (video gaming). Shouldn’t it be surrounded with <noinclude>
tags?
―PapíDimmi (talk | contribs) 19:40, 10 May 2017 (UTC)
- Way too late, but no, it is intentional for TfD tags to show up on uses. {{3x|p}}ery (talk) 22:41, 15 February 2019 (UTC)
Please use HTTPS URL for JSTOR link
![]() | This edit request to Module:Find sources/links/jstor has been answered. Set the |answered= parameter to no to reactivate your request. |
The purpose of this edit is to provide increased privacy and security for users by having the Module:Find sources/links/jstor template generate an HTTPS link to JSTOR instead of the current HTTP link. The JSTOR search URL appears to support HTTPS. In Module:Find sources/links/jstor, please change http://www.jstor.org/
to https://www.jstor.org/
instead. --Elegie (talk) 05:53, 17 May 2017 (UTC)
- @Elegie:
Done -- John of Reading (talk) 06:11, 17 May 2017 (UTC)
Update Google Images to use new-style URL and forced HTTPS
![]() | This edit request to Module:Find sources/links/google free images has been answered. Set the |answered= parameter to no to reactivate your request. |
I switched the Google Image search format string to a newer format at Module:Find sources/links/google free images/sandbox, and was hoping for it to be applied to Module:Find sources/links/google free images.
The current template uses the old-style Google image search URL format, with google.com/image?tbm=isch
instead of google.com/search?tbm=isch
. Currently the old format redirects to the new format, but I think it would be better to just use the new format to avoid any broken links in the future. Also, the protocol-relative URL scheme is now obsolete so I changed it to use https://
instead. If this is applied and works out I might make some similar changes to the other Google URLs. Thanks, Habst (talk) 15:04, 24 June 2018 (UTC)
Done — JJMC89 (T·C) 17:25, 24 June 2018 (UTC)
- @Habst: Thank you for the edit request! Fixes like these are very welcome. (And of course thank you to JJMC89 for carrying it out. :) — Mr. Stradivarius ♪ talk ♪ 12:30, 25 June 2018 (UTC)
Highbeam removed

I've removed the Highbeam link from the template, as the service is no longer working - see https://www.questia.com/hbr-welcome for the public statement. — Mr. Stradivarius ♪ talk ♪ 23:41, 4 January 2019 (UTC)
Some google searches using this module have "-wikipedia" at the end
I've noticed an issue occurring with Template:Find sources mainspace that I believe originates with this module..
An example of what is occurring:
On this diff you can see Template:Article for deletion/dated at the top. The first two Find sources links search with "-wikipedia" included in the search term, which seems to negatively affect the results coming back.
I'm hoping that someone may know what is wrong so that this can be corrected. — Preceding unsigned comment added by Vanstrat (talk • contribs) 02:09, 5 January 2019 (UTC)
RfC of potential interest

An RfC is underway that interested "watchers of this page" wound enhance by participating, I hope that many will! The discussion is located at Wikipedia talk:Twinkle#RfC regarding "Ambox generated" maintenance tags that recommend the inclusion of additional sources. Thank you.--John Cline (talk) 07:05, 29 January 2019 (UTC)
Too complicated
This module seems to me like it is needlessly complicated. Why is it a good idea to store the configuration for each template in its own module subpage instead of in the wikitext of the template? That appears to make it harder to edit for no apparent reason. {{3x|p}}ery (talk) 02:32, 15 February 2019 (UTC)
- I am guessing because auto-documentation template also uses it? — HELLKNOWZ ▎TALK 11:33, 15 February 2019 (UTC)
- It would still be possible to implement autodoc even without /templates cfg pages. {{3x|p}}ery (talk) 19:59, 15 February 2019 (UTC)
- As I have just done. I also think that the /autodoc template config pages should also be in Wikitext and associated with the template, but it's not clear exactly where. {{3x|p}}ery (talk) 21:09, 15 February 2019 (UTC)
See Wikipedia:Templates for discussion/Log/2019 February 15#Module:Find sources/templates/find sources. {{3x|p}}ery (talk) 21:54, 15 February 2019 (UTC)
Template-protected edit request on 30 July 2020
![]() | This edit request to Module:Find sources and Template:Afd2 has been answered. Set the |answered= parameter to no to reactivate your request. |
Please copy Module:Find sources/sandbox to Module:Find sources. This will allow the template to generate search queries for arbitrary page titles (specified by |title=
) with parenthetical disambiguators separated from the main part of the title (this is already supported for the current page title).
Please also copy Template:Afd2/sandbox to Template:Afd2, which will make use of this new parameter.
I posted a section on Wikipedia talk:Articles for deletion#Find sources and parenthetical disambiguiators proposing these changes. There has been no response in the past week. The testcases are unaffected. The change is demonstrated in one of my sandboxes. Danski454 (talk) 20:16, 30 July 2020 (UTC)
Done Please document the new parameter. * Pppery * it has begun... 01:02, 31 July 2020 (UTC)
Template-protected edit request on 19 August 2020
![]() | This edit request to Module:Find sources/templates/Find sources has been answered. Set the |answered= parameter to no to reactivate your request. |
Please add a link to Bing and DuckDuckGo as many people use these search engines as well when looking for sources on Wikipedia. (I use Bing myself.) Aasim 01:06, 19 August 2020 (UTC)
Not done: please make your requested changes to the module's sandbox first; see WP:TESTCASES. ProcrastinatingReader (talk) 10:32, 19 August 2020 (UTC)
Template-protected edit request on 26 November 2020
![]() | This edit request to Module:Find sources/templates/Find sources has been answered. Set the |answered= parameter to no to reactivate your request. |
Please add a link to the Open Library, a book-oriented project of the Internet Archive. I've drafted the subpage Module:Find_sources/links/openlibrary for review and testing. I would have sandbox tested it, but can't seem to find my way to the right sandbox. LeadSongDog come howl! 17:42, 26 November 2020 (UTC)
- This should be discussed at least a little before editing this widely used module. Taking the simple
{{Find sources}}
example from the {{Find sources}} documentation, what would the new output look like? Has there been any discussion about adding this? Johnuniq (talk) 22:58, 26 November 2020 (UTC)
Change "-wikipedia" to "-site:wikipedia.org"
The former is too broad; mentioning Wikipedia in of itself shouldn't be enough to disqualify a source. If some sources *cite* Wikipedia then the person looking for the sources should just not use those sources themself, rather than potentially being unaware of any source which happens to mention a widely-used website. For any topics *related* to Wikipedia especially, this template would be completely useless.
Also, the "newspapers" link should just add "&tbm=nws" as a query parameter instead of adding "site:news.google.com/newspapers" to the query string.
PBZE (talk) 04:38, 18 January 2021 (UTC)
- I was originally considering making the same request, but now I'm uncertain about it. The proposed change should be weighed, pros and cons. Using a negative site keyword, will exclude pages hosted at wikipedia.org only. Using the negative wikipedia keyword, but minus the "site:" prefix, will avoid any pages containing "wikipedia" on them. This could theoretically exclude good pages that happen to have the token "wikipedia", but I suspect that is minimal. On the flip side, it may exclude some forks and mirrors who credit wikipedia, but only if the "site:" prefix is not included. My hunch is that including the "site:" prefix will hurt more than it helps, but this would need some investigation. Mathglot (talk) 19:56, 25 June 2021 (UTC)
Please monitor WT:MED discussion
Hi. It's brand new yet, but you may wish to monitor WT:MED#Announcing new template Find medical sources. If and when it stabilizes, we can discuss what to do at that point. Mathglot (talk) 01:59, 10 August 2021 (UTC)
Discussing wording for the expansion proposal
The following discussion 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.
Hi Sdkb As mentioned here, here's my first draft for a proposal to present to the projects, VPP, etc, as you suggested. Let's try for as neutrally worded a proposal as possible, laying out the current situation, and summarizing the various ideas we've come up with. (Signed by both of us together, if that's possible; 4 tildes, ampersand, 4 tidles?) Following the neutral proposal, we could each add our own comment/!vote stating our own preference and reasons; which could be different. As you said, this affects a lot of pages, so I've gone into some detail in the 'Background' section after the proposal question. Here's my first draft for wording:
Draft 1 by Mathglot
|
---|
Proposal to facilitate use of different sets of links for different search domains
Proposal question: Do you favor an expansion of the find sources template/module to be able to facilitate generation of different sets of links for different search domains (such as medical, video games, etc.) and if so, which approach do you favor?
Votes can be combinations of more than one of the above. Background This is a proposal to expand the current functionality of {{find sources}} to include knowledge of different flavors of "find sources", and generate different sets of links according to some scheme of selection, either automatic, parametric, or by data property. Currently, we have three flavors of find sources links:
One could imagine other possible search domains in the future: perhaps other academic subect areas, biographies, country or region, and so on. This would involve creating a new {{find NewDomain sources}} template, and an update to the wrapper template to transclude it under the right conditions. Approaches The first area where this proposal was discussed in some detail is at Template talk:Talk header. Two approaches were tried in its sandbox and tested, each delivering the expanded functionality by different methods:
Both of these were found to work as expected, delivering the desired expanded functionality as shown in the testcases page (here, and here; current sandbox revision uses method 2, so testcases for method 1 currently fail, but pass successfully with the correct sandbox revision in place.) A third approach was discussed but not tested:
Design Implementation is via a wrapper template (here) which does all the detection of search domain, and transcludes the correct flavor of template. By placing the wrapper template at the current title (Template:Find sources) and moving the old content to Template:Find general sources, this remains transparent at the top level; all current transclusions of Template:Find sources after the changeover will invoke the wrapper, which invokes {{Find general sources}} by default. Outside of the Talk header template, this means a seamless transition for all other transclusions which will do exactly the same thing after go-live as they did before; that is, they will continue to invoke the basic "Find sources" link set, albeit by one extra call where {{Find sources}} transcludes {{Find general sources}} which invokes the Module. Currently Template:Talk header includes the basic set of source links for all articles where it is not suppressed by parameter. After go-live, the behavior of "find sources" in Template:Talk header may change, depending which solution is chosen. If the parameter method is chosen, then the links in the Talk header would remain the same, until someone added the parameter. If auto-detect by WikiProject is chosen, then the links in the Talk header of pages on medically-related topics will switch to the medical links, and on video-related topics will switch to the video links; all other Talk headers would remain as before. Impact on other templates Other templates use the {{find sources}} templates, such as {{unsourced}} and other maintenance templates, as well as many others. Depending which approach was chosen, this could affect whether the other templates could take advantage of them. A combined approach allowing auto-detect and via param would permit both. Thanks. /sig: Sdkb & Mathglot/ Notes
|
Please either add your own below, or change the one above to your liking. Thanks, Mathglot (talk) 19:48, 12 August 2021 (UTC)
- Thanks for writing all that out, Mathglot! It looks pretty good; the main suggestion I have is to give a little more background so that it's clearer what the proposal is. I also think that we should ask for discussion, rather than bolded !votes, around the approaches question, since it's the sort of thing that's complex enough that discussion tends to work better than a survey. Here's my draft trying to do these things:
Draft 2 by Sdkb
|
---|
Proposal to improve customization of Template:Find sources
Background This is a proposal to expand the functionality of {{find sources}}, a template frequently used in {{Talk header}} (example) to help editors find sources to improve articles. Specifically, we seek to make it possible for different sets of links to appear for different types of articles, such as links to medical sources for medical articles. Currently, there are three related templates that generate find sources links:
We anticipate that additional templates in this family for other subject areas may be created in the future. Under this proposal, talk header will choose between the available templates, either automatically or on the basis of a manually set parameter, to display the one most appropriate for a given page. Approaches for selection We are considering several possible approaches for how to select which set of links to use:
It would be possible to combine these approaches, such as through using option 2 with the option to manually override via a manual parameter. Previous discussion is at Template talk:Talk header, and we have created functional prototypes of options 1 and 2 in the talk header sandbox, which can be seen at the associated test page. (Current sandbox revision uses method 2, so testcases for method 1 currently fail, but pass successfully with the correct sandbox revision in place.) Which approach(es) would you prefer? Design We are considering implementation via a wrapper template (here) which does all the detection of search domain, and transcludes the correct flavor of template. By placing the wrapper template at the current title (Template:Find sources) and moving the old content to Template:Find general sources, this remains transparent at the top level; all current transclusions of Template:Find sources after the changeover will invoke the wrapper, which invokes {{Find general sources}} by default. Outside of the Talk header template, this means a seamless transition for all other transclusions which will do exactly the same thing after go-live as they did before; that is, they will continue to invoke the basic "Find sources" link set, albeit by one extra call where {{Find sources}} transcludes {{Find general sources}} which invokes the Module. Currently Template:Talk header includes the basic set of source links for all articles where it is not suppressed by parameter. After go-live, the behavior of "find sources" in Template:Talk header may change, depending which solution is chosen. If the parameter method is chosen, then the links in the Talk header would remain the same, until someone added the parameter. If auto-detect by WikiProject is chosen, then the links in the Talk header of pages on medically-related topics will switch to the medical links, and on video-related topics will switch to the video links; all other Talk headers would remain as before. Impact on other templates Other templates use the {{find sources}} templates, such as {{unsourced}} and other maintenance templates, as well as many others. Depending which approach is chosen, this could affect whether the other templates will be able to take advantage of them. A combined approach allowing auto-detect and via param would permit both. We look forward to your feedback on the considerations above and the proposal overall. Thanks! /sig: Sdkb & Mathglot/ |
- Let me know if it looks good! I'm thinking we can hold it at WP:VPR, with invites to the affected WikiProjects and other relevant pages. Does that seem best? {{u|Sdkb}} talk 21:10, 12 August 2021 (UTC)
- Sdkb, I like your changes overall, especially the additional background and expansion of the items in the Approaches section with the parenthetical explanations, the wording about "anticipat[ing]" future stuff, and other additions; all good! The only quibble I have, is minor, and results, I believe, from a slight difference in focus that we have in how we look at it. The way I see the focus, is that it's all about "Find sources" expanded to support all sorts of other templates, with the "Talk header" playing the role of "happens to be the first example" but with one eye fixed firmly further afield to include all the maintenance and other templates.
- If I understand you correctly, you see it focused more on "getting {{Talk header}} improved" (because we're practically there already), and worrying about other stuff later. They both amount to the same thing, really, and I'm okay with going with your approach, but I just wanted to make sure our description includes enough material about future expansion, so that any decision taken now doesn't lock us out of future expansion with other templates because it wasn't explained clearly enough at the outset.
- I think you tried to address that in the "override" comment in the first sentence after "Approaches" point 3, although I misread it at first as meaning "normally WikiData detect, but you can turn off the links entirely using 'none' in param 1". I only realized after a couple of re-reads, that you didn't mean it that way at all (amirite?). I'd like that part to be clearer about what "combined approach" is. How bout changing that sentence to:
That's a bit clunky, but I think you see where I'm trying to go with it; maybe you can come up with something smoother? Practically speaking, I think the approach of going with what we have now because it's already working makes good sense, so I'm fine with it.It would be possible to combine these approaches, such as implementing a combined option 2 – 1 approach, which in the case of {{Talk header}} would default to option 2 (project auto-detect) with the
option[a] possibility of including the parameter (e.g.,{{talk header|domain=medical}}
) which would then take precedence over the project auto-detect. Having the parameter available would also be extensible to use by other Templates on article pages where project detection isn't applicable; see below.[b] - Other than that, all good. Also, I agree with VPR as venue. One last, tiny detail: I'd like to try the "combined sig" thing if possible, so we should sign within seconds of each other or a minute or two; I've never used the #IRC channels, but maybe we could coordinate that way; otherwise, maybe an "appointment" of when to first place it, including a ping right at the end, to be replaced by the other person's sig? Or do you have a better idea? (Not married to the idea of a double-sig; just thought it would be nice.) Mathglot (talk) 22:33, 12 August 2021 (UTC)
Notes
- Sounds good! So how is this for a final draft?
Final draft
|
---|
Proposal to improve customization of Template:Find sources
Background This is a proposal to expand the functionality of {{find sources}}, a template frequently used in {{Talk header}} (example) to help editors find sources to improve articles. Specifically, we seek to make it possible for different sets of links to appear for different types of articles, such as links to medical sources for medical articles. Currently, there are three related templates that generate find sources links:
We anticipate that additional templates in this family for other subject areas may be created in the future. Under this proposal, talk header will choose between the available templates, either automatically or on the basis of a manually set parameter, to display the one most appropriate for a given page. Approaches for selection We are considering several possible approaches for how to select which set of links to use:
It would be possible to combine these approaches, such as implementing a combined option 2 – 1 approach, which in the case of {{Talk header}} would default to option 2 (project auto-detect) but would allow any editor to set a parameter (e.g., Previous discussion is at Template talk:Talk header, and we have created functional prototypes of options 1 and 2 in the talk header sandbox, which can be seen at the associated test page. (Current sandbox revision uses method 2, so testcases for method 1 currently fail, but pass successfully with the correct sandbox revision in place.) Which approach(es) would you prefer? Design We are considering implementation via a wrapper template (here) which does all the detection of search domain, and transcludes the correct flavor of template. By placing the wrapper template at the current title (Template:Find sources) and moving the old content to Template:Find general sources, this remains transparent at the top level; all current transclusions of Template:Find sources after the changeover will invoke the wrapper, which invokes {{Find general sources}} by default. Outside of the Talk header template, this means a seamless transition for all other transclusions which will do exactly the same thing after go-live as they did before; that is, they will continue to invoke the basic "Find sources" link set, albeit by one extra call where {{Find sources}} transcludes {{Find general sources}} which invokes the Module. Currently Template:Talk header includes the basic set of source links for all articles where it is not suppressed by parameter. After go-live, the behavior of "find sources" in Template:Talk header may change, depending which solution is chosen. If the parameter method is chosen, then the links in the Talk header would remain the same, until someone added the parameter. If auto-detect by WikiProject is chosen, then the links in the Talk header of pages on medically-related topics will switch to the medical links, and on video-related topics will switch to the video links; all other Talk headers would remain as before. Impact on other templates Other templates use the {{find sources}} templates, such as {{unsourced}} and other maintenance templates, as well as many others. Depending which approach is chosen, this could affect whether the other templates will be able to take advantage of them. A combined approach allowing auto-detect and via param would permit both. We look forward to your feedback on the considerations above and the proposal overall. Thanks! /sig: Mathglot/ {{u|Sdkb}} talk 23:20, 12 August 2021 (UTC) |
- Regarding co-signing, I'll set my sig to ten minutes from now; if that works, you can do the same and then just copy to VPR when it comes time. {{u|Sdkb}} talk 22:55, 12 August 2021 (UTC)
- Sounds great! (sig time check: Mathglot (talk)) Looks good; here we go.... Mathglot (talk) 23:23, 12 August 2021 (UTC)
- @Sdkb:
Done! Eager to read the feedback.
- Feel free to comment there whenever you want. I might hold off a bit, till I see if and what kind of feedback we get. One last thing: was thinking of either collapsing this thread or archiving it now, as the main action will be at VPR. What do you think? Mathglot (talk) 23:35, 12 August 2021 (UTC)
- I'll put an archive box around this, just to make sure further discussion is centralized. {{u|Sdkb}} talk 05:36, 13 August 2021 (UTC)
- @Sdkb:
- Sounds great! (sig time check: Mathglot (talk)) Looks good; here we go.... Mathglot (talk) 23:23, 12 August 2021 (UTC)
Proposal: add an icon linked to a project page with more detailed find sources information
At WP:WikiProject Women, Ipigott had an idea in this discussion (diff ) about adding a link to the list generated by "find sources" that would target a project page where more detailed information about how to find sources could be found. I think this is a really good idea, and worth considering here.
Piggy-backing on Ipigott's idea, I had a couple of thoughts about how to make it even more useful:
- to save horizontal space and also highlight the different nature of the link, we could use an icon image for it (such as
)
- the icon link could default to a standard location (perhaps Help:Find sources), and could be parametrizable, so that the link could go somewhere more specific for those articles where it made sense to do that.
Here's some mocked-up links for the Talk header of Talk:Isadora Duncan, designed to simulate a proposed inclusion of an icon with parameterized override of the default destination, to point instead to a page under WP:WikiProject Women in Red, which is specifically about finding biographical sources for women:
![]() | Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL ![]() |
Thoughts? Adding SusunW, who was involved in these discussions. Mathglot (talk) 01:44, 17 August 2021 (UTC)
- I definitely like the thought of {{find sources}} adjusting by project; that's what the {{Find video game sources}} and {{Find medical sources}} already do. My sense is, though, that structuring it as a separate click people will need to make will likely greatly reduce the number who do so.
- There are a bunch of possible changes currently up in the air, so if you want to pursue this further, waiting for those to settle first might make it easier. {{u|Sdkb}} talk 02:45, 17 August 2021 (UTC)
- Yah, probably so. This just happened to come up when it did, and thought it best to raise it while I still remembered it. We can shelve this till some later point when other things shake out one way or the other. Although I didn't get the part about "structuring it as a separate click" so remind me to ask about that when (if) it comes up again later. This isn't meant to be any kind of separate click, just a link like the others, except instead of going to an offsite database search page that generates search results for a particular topic, this would go to an on-site project page that has links to multiple sources, unrelated to the search keywords. Somewhat like TWL is now. Mathglot (talk) 10:59, 17 August 2021 (UTC)
Multiple RS link sets in a single topic
Mathglot and Sdkb previously came up with a great proposal to improve Template:Find sources. By adding some simple logic to the template that pivots off WikiProject banners, Template:Find sources can produce a RS link set that is more relevant to each topic. A manual override would be built in to disable this at the topic level.
The Village Pump Proposal received consensus to move forward. One lingering question from that discussion was how to handle topics that might benefit from multiple RS link sets. For example, Talk:Medtronic is part of both WikiProject Medicine and WikiProject Companies. The topic could benefit from both MEDRS and standard RS links.
Approaches
We could stack the best matching link sets (temporary mockup) or detect a conflict and revert to the basic set. I have no preference.
Thoughts? - Wikmoz (talk) 04:54, 22 September 2021 (UTC)
- I had thought about this, and came up with the same approaches you identified:
- include two (or multiple) stacked "find source" link sets, as in the mockup
- define a WikiProject hierarchy based on "source strictness" and include only the most general one. In this approach, if Medtronic is in projects Companies and Medicine, and sourcing for "Companies" is defined as 'RS' (general) while sourcing for "Medicine" is 'MEDRS' (strict) then Talk:Medtronic would get only the more general {{Find sources}} list.
- Of these two approaches (there may be others), I think I prefer the first, in order to address Spicy's comment of 19:54, 13 August (diff, perma) at the proposal. Whether it (or either one) should be implemented in the initial launch or as a refinement later is a separate question. Mathglot (talk) 05:31, 22 September 2021 (UTC)
- Unless a better solution is proposed, I support this approach. Seems clean and transparent in its functionality. - Wikmoz (talk) 03:12, 23 September 2021 (UTC)
- I think having multiple link sets would be best. I don't think it's helpful to exclude specialized sources in favour of general sources, or vice versa, if both might be useful for the article. The current mockup looks a little clunky but I'm sure the presentation can be improved. Spicy (talk) 16:34, 22 September 2021 (UTC)
Priority
This seems like a lower priority edge case. So whatever the resolution, it seems safe to defer this to a future update. The previously-discussed manual override could be used as a short term fix in some topics. - Wikmoz (talk) 03:12, 23 September 2021 (UTC)
Repeating the search in what's displayed
Sometimes I add a second or third to an AfD when I think that searching for references by an alternate name (often in a different script such as Cyrillic or Chinese) would be helpful. It would be helpful if {{Find sources AfD}} could display what's being searched for so that readers recognize that the second or third instance is looking for a variant spelling or different script. Eastmain (talk • contribs) 19:58, 27 September 2021 (UTC)
Wikipedia Library text
"TWL" is not a widely known acronym, even among experienced Wikipedians. I'd suggest changing it to "Wikipedia Library". {{u|Sdkb}} talk 05:08, 10 August 2021 (UTC)
- @Sdkb:That's a pretty long name, and might cause the "find sources" links to wrap at some window widths, when space is at a premium. Sample links currently for
{{find sources|Egypt}}
: - Sample links including Wikipedia Library instead of TWL:
- How 'bout, "WikiLib", instead? Alternatively, I've been thinking about adding tooltips and this would be a good candidate for one. (Tooltips active in the last four links in second row above.) I know, I know; a tooltip won't help mobile users, but I can't see a mobile user going through the long and involved sequence of steps starting from a list of find source links, to TWL (heh heh...), and then the whole procedure required to log in, find a source, generate a citation, and come back to the original article and add it. I do some intricate stuff on mobile, but this would be just too much for me. If there's anyone who would attempt it on their smartphone, I know who it is. Let's see what Cullen328 says. Mathglot (talk) 21:28, 10 August 2021 (UTC)
- I consider my smartphone to be a miniature computer capable of doing almost any type of edit that can be done on a desktop computer. The problem is not the devices. It is the crappy mobile sites and mobile apps that the WMF has cooked up. That is why I always use the desktop site on my mobile phone, and I go though the process described above all the time. It is not really difficult. Cullen328 Let's discuss it 21:36, 10 August 2021 (UTC)
- I think tooltips definitely has potential! If we need a slightly shorter name, we could use
WP Library
. If there's agreement to remove Google newspapers as I propose below, that'll reclaim some space. {{u|Sdkb}} talk 22:00, 10 August 2021 (UTC)
- I think tooltips definitely has potential! If we need a slightly shorter name, we could use
- @Mathglot, following up, per the documentation at {{tooltip}} and MOS:NOHOVER, there are some accessibility concerns around using the tooltip to provide information about the sources, rather than just providing the abbreviation. But the counterargument is that something for some users is better than nothing for everyone. I'll implement the abbreviations now, and if we find consensus for including explanations in the tooltips, I'm fine with adding that element, but I just want to be cautious given that this is an 800k-transclusion template. {{u|Sdkb}} talk 20:05, 30 September 2021 (UTC)
- @Sdkb:, yes, and I have always been on the fence about tooltips because of NOHOVER. I tend to favor inclusion due to the "some users" issue you raised (and also because of Cullen328's comment; he's quite right that it is an interface issue, not a device issue; tooltips *do* work on mobile in Desktop view). One of the reasons I lean towards inclusion, is that if we didn't include stuff merely because of inability of "some other users" inability to see it due to their chosen interfaces being unable to render it, then we should stop leaving user warning messages on user talk pages entirely; obviously, that won't fly. The other reason is that NOHOVER seems directed more at article than talk space. WP:THEYCANTHEARYOU is a larger issue for another venue, but it explains why I lean towards inclusion of tooltips here. Note that the new {{Find biographical sources}} uses tooltips extensively, but I won't squawk if consensus is opposed and removes them (but I would like to see and participate in that consensus). Mathglot (talk) 21:18, 30 September 2021 (UTC)
- I consider my smartphone to be a miniature computer capable of doing almost any type of edit that can be done on a desktop computer. The problem is not the devices. It is the crappy mobile sites and mobile apps that the WMF has cooked up. That is why I always use the desktop site on my mobile phone, and I go though the process described above all the time. It is not really difficult. Cullen328 Let's discuss it 21:36, 10 August 2021 (UTC)
- Just a side note on this - since we started rolling out some design improvements this month, I think the best place to link to for TWL is now https://wikipedialibrary.wmflabs.org/ rather than the current destination. In terms of names, I'll just quickly say that I think "WikiLib" would be confusing, it's not a term we've used anywhere else, but "WP Library" is probably fine. Samwalton9 (WMF) (talk) 09:12, 13 August 2021 (UTC)
- Sorry I missed this before; changing the link sounds fine to me! {{u|Sdkb}} talk 01:13, 1 September 2021 (UTC)
- Support renaming "TWL" to "WP Library". I don't have template editor permissions but perhaps Mathglot or Sdkb could implement the change? - Wikmoz (talk) 17:54, 30 September 2021 (UTC)
- Sorry I missed this before; changing the link sounds fine to me! {{u|Sdkb}} talk 01:13, 1 September 2021 (UTC)
Template-protected edit request on 30 September 2021
![]() | This edit request to Module:Find sources/templates/Find sources and Module:Find sources has been answered. Set the |answered= parameter to no to reactivate your request. |
@Wikmoz: I think there's consensus to change TWL
to WP Library
, FENS
to FENS
, and NYT
to NYT
. However, looking at the code, I'm not sure how to get the tooltips to work properly in the module, so I'm opening an edit request to draw in someone who knows how. {{u|Sdkb}} talk 20:24, 30 September 2021 (UTC)
- I've made edits to the sandboxes, it looks like this:
- Lua error in Module:Find_sources/sandbox at line 88: invalid template name 'Find sources/sandbox'; no template config found at Module:Find sources/templates/Find sources/sandbox/sandbox.
- Can someone please copy Module:Find sources/sandbox and Module:Find sources/templates/Find sources/sandbox to their respective main pages. Danski454 (talk) 16:48, 1 October 2021 (UTC)
Done User:GKFXtalk 18:46, 4 October 2021 (UTC)
- Sorry I missed this earlier, @Danski454; thanks for coding and thanks @GKFX for implementing. I just switched to non-breaking spaces, and the other change it'd be nice to see is for The New York Times to be properly italicized if either of you know how to do that.
- I am noticing that this is causing {{Find sources}} to go onto two lines on many pages, at least on my display. If either of you have thoughts on the proposal immediately below, it'd be nice to implement that soon to get it back on one line. {{u|Sdkb}} talk 01:55, 5 October 2021 (UTC)
Your feedback would be appreciated at Village pump proposals
There is a discussion going on at Village pump (proposals) about expanding the functionality of Template:Find sources to facilitate the generation of different sets of "find sources" links, depending on the search domain (general, medical, video, etc.). Your feedback would be welcome at WP:VPR#Proposal to improve customization of Template:Find sources. Thanks, Mathglot (talk) 22:21, 13 August 2021 (UTC)
Courtesy link: Wikipedia:Village pump (proposals)/Archive 184 § Proposal to improve customization of Template:Find sources Mathglot (talk) 00:38, 17 October 2021 (UTC)
Google News vs. Newspapers
Having links to both Google News and Google Newspapers is confusing. The News link is the one most people are going to want, whereas the newspapers link goes to a subset of the results from Google Books (which also apparently has newspapers) and is therefore redundant to the books link we already have. I'd suggest removing the newspapers link. {{u|Sdkb}} talk 05:11, 10 August 2021 (UTC)
- If the consensus is to keep it, tooltips might help here as well. See section #Wikipedia Library text above for more about this. The other aspect to this, is that Newspapers.com is available at the Wikipedia Reference Library (already linked) and that's really where you want to go, for those who have access to it. Mathglot (talk) 21:45, 10 August 2021 (UTC)
- Support removing "newspapers". I didn't know Google had this function. It's really cool. However, given the age and limited size of the archive, I doubt it's going to help editors in 99% of use cases. - Wikmoz (talk) 18:04, 30 September 2021 (UTC)
- Lean support – Unsure about removing newspapers; can you elaborate? I haven't looked in detail, but a few searches seems to show "news" = weighted to current events and online versions of news sources which may have more content than their printed paper, or at least, different content; while "newspapers" seems much less weighted to current events, and as you say, may be a subset of books; a kind of proxy to older, archival copies of newspaper content (a bit more like searching newspapers.com). Otoh, I see distinguishing "newspapers" from "news" in the mind of the viewer as a big enough problem to maybe just cinch the deal right there and remove it—I can't think of a simple way to disambiguate those two without lengthy clarification, and we don't have the real estate for that, and viewers won't have the patience for it, even if in a perfect world both of them might be useful. So I guess, yeah. Mathglot (talk) 21:14, 17 October 2021 (UTC)
Done here, taking into consideration Mathglot's "yes to both" comment below. {{u|Sdkb}} talk 21:50, 17 October 2021 (UTC)
Why does this link to Google?
While it may be true that Google indexes a lot of websites, the use of its services requires the user to be subjected to proprietary software; furthermore, it is well-known that Google is very privacy-invasive. On a site like Wikipedia, which was founded on the ethos of freedom and ethics in software and technology, why are we heavily linking to a company's services that are the complete opposite of that? DesertPipeline (talk) 10:41, 12 March 2021 (UTC)
- Indeed, it's quite puzzling. Especially as it does so without warning: if I see a link for "scholar" I may think it goes to Internet Archive scholar instead. DuckDuckGo is a more suitable target. Nemo 07:54, 3 November 2021 (UTC)
Systemic bias
As mentioned a couple of times before, I think including the NYT is symptomatic of a systemic bias in favour of the USA. I don't think it should be there as the only newspaper represented. Stifle (talk) 09:51, 12 May 2021 (UTC)
- What would you suggest doing instead? Nikkimaria (talk) 11:40, 12 May 2021 (UTC)
- The Guardian is an easy replacement, as it's non-profit and non-paywalled. It's still western-centric and tends to carry a lot of pro-NATO propaganda, but slightly less so than the NYT. It's used on a comparable number of articles, indicating the editors find it useful.
- It's also possible to link the news tab of DuckDuckGo, whose representation bias is less harmful than on other news sources, because at least there is a geography/culture selector which the bias-aware person can use to tune the results for higher cultural diversity. Nemo 07:58, 3 November 2021 (UTC)
Google News: "Archives", not "recent"
If anyone can figure out the URL structure, I think Google News links should go to a results list with the "archives" option set (which fetches results from all time without prejudice toward more recent items) rather than the default "recent" option. This will turn up more relevant results for more obscure topics and avoid WP:RECENTISM. Thoughts? {{u|Sdkb}} talk 05:13, 10 August 2021 (UTC)
- Following up on the technical side, it looks like we just need to add
&tbs=ar:1
to the URL. Courtesy pinging the other two editors who have been active here recently, @Mathglot and Wikmoz: Would you support this? {{u|Sdkb}} talk 00:53, 17 October 2021 (UTC)
- Oh, this seems to handle the concern I had at the News vs. Newspapers section just above; so, yes to both seems to handle my concerns. Mathglot (talk) 21:36, 17 October 2021 (UTC)
- Sdkb, It looks like newspapers was removed byt the "&tbs=ar:1" parameter wasn't added. Is it still the plan to add that? - Wikmoz (talk) 05:15, 31 October 2021 (UTC)
- I was just waiting for a little more confirmation of consensus, but now
Done here; thanks for the follow-up! {{u|Sdkb}} talk 06:21, 31 October 2021 (UTC)
- I support both too, in case that helps! I had meant to say so earlier, but I was waiting to see whether more-experienced editors would comment more, and then I forgot where this discussion was and didn't find it again until now. —2d37 (talk) 10:28, 15 November 2021 (UTC)
- I was just waiting for a little more confirmation of consensus, but now
- Sdkb, It looks like newspapers was removed byt the "&tbs=ar:1" parameter wasn't added. Is it still the plan to add that? - Wikmoz (talk) 05:15, 31 October 2021 (UTC)
At least one source doesn't play nice with special characters

We might need some pre-processing for accented letters. Take the example of Charlotte Brontë:
- Find biographical sources: Britannica · British Library · EoWB · books · Guardian · Infoplease · JSTOR · Library of Congress · MUSE · NYT · TWL
The InfoPlease link doesn't process the ë
properly (it looks like invalid or escaped UTF-8 conversion: displays as %C3%AB
). The InfoPlease result page does have a <meta charset="utf-8" />
but even the result pages when searched without the accented letter completely omit the final -e, and she shows up as "Charlotte Bront", so the problem seems to be on their side, and maybe preprocessing the ë
won't even help. There may be other cases where pre-processing to strip accents for some destination sites could help, so need to keep aware of that case. Mathglot (talk) 03:55, 14 August 2021 (UTC)
- Oh, I didn't realize in the comment I just made a minute ago at Template talk:Talk header that this is a new template you just launched! Is there a reason you didn't build it through the find sources module? I'd think we'd want to stick with the process that module established for creating new find sources templates. {{u|Sdkb}} talk 07:09, 14 August 2021 (UTC)
- Only that it's easier to delete this than mess around with the Module in case this doesn't fly. It's kind of a live testing ground, more than a sandbox, less than a module update. If approved, it should definitely be adopted in the module, but there may be a lot of tweaks based on feedback, before it stabilizes, so thought that would be easier to accomplish that here than there. Hope that makes sense. Mathglot (talk) 10:13, 14 August 2021 (UTC)
Issues with specific links

The Guardian
This is covered already at Template talk:Newspaper of record#The Guardian. Mathglot (talk) 00:31, 15 August 2021 (UTC)
Library of Congress
In the form dropdown for search format (param &in=
) the default choice for the form selector is 'Everything' which returns a null value, so the url string contains &in=
with no value. That works fine when going direct to the site and entering a query, but for some reason it doesn't from the template. For the time being, I've coded it to include the drop down selector 'Books/Printed Material', which returns original-format:book
as the value for &in=
, so it's currently coded as &in=original-format:book
. The problem is, that gives pretty crappy results for some searches; try clicking LoC in this example using query 'Hamid Karzai':
Find biographical sources: Britannica · British Library · EoWB · books · Guardian · Infoplease · JSTOR · Library of Congress · MUSE · NYT · TWL |
and after the crappy results come back, then click 'Everything' in the drop-down and search again, and watch how much the results improve. Mathglot (talk) 00:48, 15 August 2021 (UTC)
- Okay, tweaked the url and got it to work, but it was hella slow (30"), so restored sone one param that I didn't think we needed and one empty param (
&new=true&st=
) and now it seems to work okay. Mathglot (talk) 01:04, 15 August 2021 (UTC)
Trying Alexander Street, Hathi

Inspired by a conversation at WT:WOMEN, added some links including HathiTrust and Alexander Street. Here's how it looks in sandbox rev. 1038969680:
Thanks, Mathglot (talk) 22:26, 15 August 2021 (UTC)
Creation

Created as a duplicate of {{find sources}}, rev. 1018938532, in partial satisfaction of the implementation of a choice among three (or more) different sets of links presented by {{find sources}} based on some selector, such as |search-domain=
, presence of specified WP:WikiProjects on the Talk page, or certain WikiData properties. This template is the unmarked case and represents the links displayed in the general case where no selector is detected or specified. As such, it inherits the code of the previous {{find sources}} template and [re-]implements its functionality. Mathglot (talk) 06:36, 12 August 2021 (UTC)
- @Mathglot, the VPR discussion has been archived and I think it's pretty safe to say it found consensus. Any updates on this? {{u|Sdkb}} talk 20:31, 30 September 2021 (UTC)
- @Sdkb: agreed; I've had a rough jet-lag adaptation and have been sticking to low-complexity stuff. I'll get back to this in a copla days. Adding Wikmoz, who asked a similar question somewhere. Mathglot (talk) 20:57, 30 September 2021 (UTC)
- Sounds good! {{u|Sdkb}} talk 20:59, 30 September 2021 (UTC)
- If we can assist, please let us know. I can take a swing at modifying Template:Find biographical sources/sandbox to use modules the same way Template:Find video game sources is set up--if that is the correct module pattern to replicate. - Wikmoz (talk) 18:22, 6 October 2021 (UTC)
- Sdkb, Mathglot: it appears everything starts with the link entries? I added The British Library and Library of Congress to Module:Find sources. If this looks right, let me know and I'll run down the remainder of missing links. - Wikmoz (talk) 23:37, 7 October 2021 (UTC)
- I now understand the basic structure of the Module:Find sources and was able to get Template:Find biographical sources/sandbox set up. I also now see Mathglot's preference for holidng off on setting up the modules until things are more final. Let me know if it's better to hold off and just launch with the static templates. I have no idea what's involved in setting up the conditional display logic. Help us, Mathglot. You're our only hope. - Wikmoz (talk) 19:06, 12 October 2021 (UTC)
- @Sdkb: agreed; I've had a rough jet-lag adaptation and have been sticking to low-complexity stuff. I'll get back to this in a copla days. Adding Wikmoz, who asked a similar question somewhere. Mathglot (talk) 20:57, 30 September 2021 (UTC)
Encyclopedia of World Biography

Not seeing any results from the Encyclopedia of World Biography in the University of Michigan search. Any objections to removing the EoWB link? - Wikmoz (talk) 00:38, 8 October 2021 (UTC)
Biographical sources
Updated in the module (see rev. 1060706179) to match the old, "manual" version of the template (e.g., rev. 1053768182), and repointed the template at it, in rev. 1060724238 (diff). This is ready for prime-time. We could advertise this at WP:BLP just as an available template, without necessarily proposing WikiProject autodetection used in projects VG and MED, or we could mention that, too.
Example (using "J. K. Rowling"; from the notice box wrapper incorporating the template):
Find biographical sources: Britannica · British Library · EoWB · books · Guardian · Infoplease · JSTOR · Library of Congress · MUSE · NYT · TWL
Adding @Sdkb and Wikmoz:. Mathglot (talk) 08:26, 17 December 2021 (UTC)
- Sorry for the delay... I've been buried in some other projects. I think we paused work on this one because the source list was still in flux. Definitely worth kicking off the discussion at WP:BLP. - Wikmoz (talk) 05:10, 24 December 2021 (UTC)
Wikipedia library
- Copy of discussion originally at Template talk:Find sources#Wikipedia library.
Just a quick note that the Wikipedia Library link should point to https://wikipedialibrary.wmflabs.org/ rather than /partners, as the correct entry point for accessing content :) Samwalton9 (WMF) (talk) 11:02, 29 October 2021 (UTC)
- I've updated that (in Module:Find sources/links/wikipedia library), since it's really independent of the rest of the rollout. * Pppery * it has begun... 17:27, 29 October 2021 (UTC)
- (edit conflict) Samwalton9, I took another look. When I go to the domain home I'm unable to access any resources, nor even see which ones are available. A better choice, it seems to me, is https://wikipedialibrary.wmflabs.org/users/my_library/ which for a logged-in user provides a search box that when filled and submitted will execute a search on the sources they have access to. (A non-logged in user gets a WM login page, which then proceeds directly to the search page.) Ideally, we'd prefer to skip the page with the search box and just execute the search directly upon clicking the link (as we do for every other link in the find-sources set except for that one) but in the case of WP library the search is executed by ebscohost.com which requires url params that encode session data from the logged-in user and other information (unlike all the others) and so we're unable to do that. But it seems to me that going to the 'my_library' gets the user as close as possible to the WP Library results they are seeking; it still requires them to fill the search box and hit Submit, but nevertheless it's better than the domain home page. Unless there's something I'm missing, in my opinion we should use the my_library address. It's second-best compared to showing the search-results directly, but the best we can offer now. (Domain eds.s.ebscohost.com stores two session cookies, and maybe down the road an enterprising js- and template editor could look into whether session or other information could be extracted to provide the missing ebsco query params and execute the search directly, but that's well beyond the scope of this implementation.) Mathglot (talk) 18:21, 29 October 2021 (UTC)
- Pppery, thanks for that. My response above had an edit conflict. Can you take another look at the module url for WP Lib in light of this information, and if Sam agrees with the reasoning, adjust the link in the module again as needed? (P.S., in refactoring this to a subsection, I dropped an indent level, thus technically a TPO-vio; hope you're okay with this.) Mathglot (talk) 18:25, 29 October 2021 (UTC)
Mathglot (talk) 20:48, 29 October 2021 (UTC)
- @Mathglot: I suggested linking to the homepage so that users might understand what they're logging into before continuing. If we linked to https://wikipedialibrary.wmflabs.org/users/my_library/, then the first prompt a new user of the library would see would - I think - be the OAuth confirmation, which might be confusing. This is especially the case if the user isn't actually eligible for the library. They'll approve a mystery OAuth prompt, and then be shown a 'you are not eligible' screen. I know it's an extra click but at least if they've seen the homepage they understand what they're logging into in advance. Ultimately your choice though, that's just my opinion :) The question of automatically searching for a term like the other links is an interesting idea, and I think you've hit upon the reasons it's not immediately obvious how that would work technically, but I'll chat to our engineers and see if there might be something we can do. Ultimately users would still need to log in first though. Samwalton9 (WMF) (talk) 09:33, 1 November 2021 (UTC)
- User:Samwalton9 (WMF), thank you for your comments. I disagree with setting the link to the home page. When I signed up to TWL, the only users who could use the library resources were the ones who had previously signed up for it and received access; is it still that way? The WP Lib access from find_sources currently is not ideal, because it requires additional user input, namely, entering a query and clicking the search button. Every other "find sources" link but this one provides direct access to the SRP (search results page) for the given query; only the WP lib requires an extra click, or in this case, typing in the query, and then clicking. At least, that is the case on the my_library page. However from the homepage, we are even further from the SRP, and would require yet another click. That is the opposite of the direction we want to be going.
- I realize this would require software changes, but my preference would be to make such modifications as are necessary to execute the ebscohost-domain url that actually executes the search query at WP Lib directly from the WP Lib url in the "find sources" link, so that when someone clicks "WP Library", they get the SRP already filled in with the results from a WP Library search already on it, no other clicks, no typing the same query over again.[a] Naturally, this would only work when they are logged in, but users that use WP Library will be logged in. (If not, they'll get the login page and know what to do; as I recall, "prev-url" is stored and will activate automatically following the login.)
- Anyway, that should be the goal for what happens when you hit the "WP Library" link in "find sources", even if that's not where we are now, and may not be for some time. Following your suggestion would be going in the opposite direction in my opinion, and I would be opposed to it for that reason. As for the inchoate proposal, what is the best venue to do that: WP:VPR, Phab, someplace on mw, or meta? Mathglot (talk) 20:44, 1 November 2021 (UTC)
Notes
- ^ Maybe a preference option allowing a user to opt in to storing WP Lib login session ids, and then an appropriate indicator, such as a new magic word or a template to access the information needed to generate an ebscohost url containing all the session/userid information (or whatever else) as well as the query information to the url?
- @Mathglot: I hear what you're saying and agree clicking straight through to results for the relevant search term would be ideal. I'll chat with the team at our engineering meeting tomorrow and see if we can find a good way to facilitate this.
- "When I signed up to TWL, the only users who could use the library resources were the ones who had previously signed up for it and received access; is it still that way?" - Users logging in to the library now have their eligibility checked automatically and receive access to a set of ~30 automatically-granted collections, and can then file applications to access others. Any eligible user can access these collections without any pre-approval. Does that answer your question? Samwalton9 (WMF) (talk) 10:38, 2 November 2021 (UTC)
- @Samwalton9 (WMF) and Sam:, Aha, yes it does, and that's a big improvement, as well as a leap forward in sustaining WP:Verifiability! Thanks for taking this on with the team, and I'll be very interested in how it goes. I'm sure a wider audience will be interested in following this, too, so I'll probably open a brief summary discussion at WP:VPR to let folks know this is going on, unless you prefer a venue at mw or meta or wherever; lmk. Thanks again, Mathglot (talk) 17:25, 2 November 2021 (UTC)
- @Mathglot: I chatted with our engineers and it looks like it should be very feasible for us to implement a URL pattern which initiates a library search. You can track progress on this work at T294919. Samwalton9 (WMF) (talk) 14:23, 3 November 2021 (UTC)
- @Samwalton9 (WMF):, that's really excellent news! I believe that in its small way over time, implementation will help lead to greater acceptance and increased use of the Wikipedia Library by editors who visit Talk pages, which in turn will provide better support for Wikipedia's core principle of WP:Verifiability. I really appreciate your taking this up; thanks again. Mathglot (talk) 17:54, 3 November 2021 (UTC)
- @Mathglot: I chatted with our engineers and it looks like it should be very feasible for us to implement a URL pattern which initiates a library search. You can track progress on this work at T294919. Samwalton9 (WMF) (talk) 14:23, 3 November 2021 (UTC)
Search-url feature launched
The new "direct-search" url for Wikipedia library has been launched, and is now incorporated in the module config in this template as the link format for this search. This means that everywhere that "find sources" displays a 'WP Library' link, you can click the link and go straight to a page of search results.
For those wishing to use a Wikipedia Library link directly on a Talk page, you can do that, too, like this:
https://wikipedialibrary.wmflabs.org/search/?q=<your urlencoded query>
The Wikipedia Library query recognizes double-quoted terms as "exact search", and boolean operators AND, NOT, and OR; minus sign is *not* a synonym for NOT. Details on urlencoding here, but as a first cut, just replace blanks in your query with +
and double-quote characters with %22
. Thus, you could have the following query:
- https://wikipedialibrary.wmflabs.org/search/?q=%22myocardial+infarction%22+NOT+patients+NOT+clinical
giving these results. Mathglot (talk) 21:06, 11 November 2021 (UTC)
- @Mathglot: Small update to this, we got The Wikipedia Library added to the Interwiki map, so this link could now use [[twl:TITLE]] instead, if that seems preferable. Up to you. Samwalton9 (WMF) (talk) 15:27, 28 January 2022 (UTC)
- @Samwalton9 (WMF):, that's great news, thanks! Adding users @Wikmoz and Sdkb:. Mathglot (talk)
- Fantastic! URL encoding isn't too hard—it's just the magic word
{{urlencode:dfgsjkdfghsdlf}}
—but an interwiki option is even better. Let's absolutely integrate this into the find sources module! {{u|Sdkb}} talk 18:32, 28 January 2022 (UTC) - The main thing tempering my excitement remains that it's incredibly difficult to cite something found on EBSCOhost properly (using
|id={{EBSCOhost}}
). {{u|Sdkb}} talk 18:36, 28 January 2022 (UTC)
- Fantastic! URL encoding isn't too hard—it's just the magic word
- Testing:
[[twl:"myocardial+infarction"+NOT+patients+NOT+clinical]]
= - Looks good! (Possibly we should add a test case or two.) Mathglot (talk) 18:59, 28 January 2022 (UTC)
- @Samwalton9 (WMF):, that's great news, thanks! Adding users @Wikmoz and Sdkb:. Mathglot (talk)
What is the purpose of the "as_eq=wikipedia" parameter for Google Search?
Not that it bothers me, but it appears that no one has asked this so far. --79.249.159.172 (talk) 20:33, 19 January 2022 (UTC)
- That's to exclude wikipedia results from the query. It's possibly too broad and maybe site exclusion would be better. Mathglot (talk) 19:05, 28 January 2022 (UTC)
Extra search links from old (now-deleted) template
Following this discussion it wad decided to merge {{Friendly search suggestions}} into {{talk header}}, the latter of which calls this module. The transclusions of the former template were removed but the merge has not fully taken place yet. However, people have started re-adding the FSS template, so I have deleted it again. The relevant content/search capabilities of the template are below. They were copied from Special:PermaLink/1037650204. Do with this what you will.
| text = You can help improve this article! Perform a search for up-to-date information by using these '''search tools''': <div class="hlist">
* {{#invoke:Find sources|Find sources|{{{1|{{SUBPAGENAME}}}}}}}
* {{Find sources multi/archive|{{{1|{{SUBPAGENAME}}}}}}}
* {{Find sources multi/bing|{{{1|{{SUBPAGENAME}}}}}}}
* {{Find sources multi/ddg|{{{1|{{SUBPAGENAME}}}}}}}
* [https://fist.toolforge.org/fist.php?doit=1&language=en&project=wikipedia&data={{urlencode:{{{1|{{SUBPAGENAME}}}}}}}&datatype=articles¶ms%5Bcatdepth%5D=0¶ms%5Brandom%5D=50¶ms%5Bll_max%5D=5¶ms%5Bcommons_max%5D=5¶ms%5Bflickr_max%5D=5¶ms%5Binclude_flickr_id%5D=1¶ms%5Bwts_max%5D=5¶ms%5Bgimp_max%5D=5¶ms%5Besp_max%5D=5¶ms%5Besp_skip_flickr%5D=1¶ms%5Bgeograph_max%5D=5¶ms%5Bforarticles%5D=noimage¶ms%5Blessthan_images%5D=3¶ms%5Bdefault_thumbnail_size%5D=¶ms%5Bjpeg%5D=1¶ms%5Bpng%5D=1¶ms%5Bgif%5D=1¶ms%5Bsvg%5D=1¶ms%5Bogg%5D=1¶ms%5Bmin_width%5D=80¶ms%5Bmin_height%5D=80&sources%5Blanguagelinks%5D=1&sources%5Bcommons%5D=1&sources%5Bflickr%5D=1 Free image search]
* [https://www.gigablast.com/search?c=main&q={{urlencode:{{{1|{{SUBPAGENAME}}}}}}} Gigablast]
* [https://academic.microsoft.com/#/search?iq={{urlencode:%40{{{1|{{SUBPAGENAME}}}}}%40|PATH}}&q={{urlencode:{{{1|{{SUBPAGENAME}}}}}|PATH}} Microsoft Academic]
* [https://www.questia.com/searchglobal#!/?keywords={{urlencode:"{{{1|{{SUBPAGENAME}}}}}"}}!AllWords&pageNumber=1&mediaType=books Questia]
* [https://www.worldcat.org/search?fq=x0:book&qt=advanced&q={{urlencode:"{{{1|{{SUBPAGENAME}}}}}"}} WorldCat]
* [https://search.yahoo.com/search;_ylc=X3oDMTFiN25laTRvBF9TAzIwMjM1MzgwNzUEaXRjAzEEc2VjA3NyY2hfcWEEc2xrA3NyY2h3ZWI-?p={{urlencode:{{{1|{{SUBPAGENAME}}}}}}}&fp=1&toggle=1&cop=mss&ei=UTF-8 Yahoo]
* [https://www.yandex.com/search/?msid=1501758427.20016.22894.2840&text={{urlencode:{{{1|{{SUBPAGENAME}}}}}}}&lr=21074 Yandex]
* [https://www.washingtonpost.com/newssearch/?query={{urlencode:{{{1|{{SUBPAGENAME}}}}}}}&sort=Relevance ''Washington Post'']
Primefac (talk) 11:48, 24 January 2022 (UTC)
- Hm; as a start, we could add link configs for them and a template config for FSS, but I've got no time for this in the near term (month or two). Pinging @Sdkb and Wikmoz: in case anyone feels like looking at this sooner. Mathglot (talk) 19:02, 28 January 2022 (UTC)
- It would be helpful if an advocate for any one of these sources propose it as an addition to the current {{Find sources}} template. Questia and Microsoft Academic are no longer operational. Yahoo Search is just Bing. I'm not sure what Gigablast brings to the table. There are some relevant discussions relating to Google and the New York Times that may be relevant and could use additional editor engagement. - Wikmoz (talk) 05:52, 29 January 2022 (UTC)