Template talk:cite-web

The following information passed a request for deletion.

This discussion is no longer live and is left here as an archive. Please do not modify this conversation, but feel free to discuss its conclusions.

---

What's up with this? We're not Wikipedia. Better to get rid of it than to have it mislead people into believing that uses from the web count as citations here. --Μετάknowledge^{discuss/deeds} 23:21, 22 September 2012 (UTC)

We do still need references for etymologies and such... —CodeCat 23:39, 22 September 2012 (UTC)

Keep per Special:WhatLinksHere/Template:cite_web, which indicates that the template is used in thousands of pages.

AFAIK, uses from the web do count as citations for their main purpose, which is illustrating the usage of words. They don't count for RFV/attestation, though, which is a completely separate matter. --Daniel 15:16, 24 September 2012 (UTC)

Keep, because erm, keep. Mglovesfun (talk) 17:33, 24 September 2012 (UTC)

I don't quite agree with your first argument Daniel. The fact that a template is used in thousands of pages is not an argument against deleting it. It only means that we can't delete it yet, but RFD should concern itself with whether things ought to be deleted, not whether they can be. —CodeCat 17:48, 24 September 2012 (UTC)

Keep. This is a reference template (for use in <ref> tags and ===References=== sections), not a quotation template (for use under sense-lines and in ===Quotations=== sections and on Citations: pages). Like most of our general-purpose reference and quotation templates, it's poorly named, poorly conceived, poorly formatted, and poorly written; but I don't think that RFDO is the place to address that. —Ruakh_TALK 17:45, 24 September 2012 (UTC)

Keep per CodeCat and Ruakh. - -sche (discuss) 19:40, 6 October 2012 (UTC)

Kept. BTW, RFD tag could have been added to documentation page instead, correct? DAVilla 03:38, 9 October 2012 (UTC)

Asking for title which is already provided

{{cite-web|title=Here we go|url=http://www.example.com|date=2018-07-07}} →

“Here we go”, in (Please provide the book title or journal name)‎^[1], 2018 July 7

As you can see the title is provided but the template is still asking for it:

(Please provide the title of the work))

Any ideas? --Alexander Davronov (talk) 21:04, 7 July 2018 (UTC)

The parameter |title= in this case refers to the title of the specific webpage, while you need to use |work= to specify the name of the website as a whole. See the documentation. — SGconlaw (talk) 06:48, 8 July 2018 (UTC)

The wording could be better. I had to read the template documentation to understand what to add Akeosnhaoe (talk) 03:35, 11 April 2021 (UTC)

That’s what the documentation is for! You can also look at the examples. — SGconlaw (talk) 03:40, 11 April 2021 (UTC)

It would be better if the error message wasn't confusing. Akeosnhaoe (talk) 19:39, 19 April 2021 (UTC)

|workurl=

@Sgconlaw, Erutuon, if either of you are inclined, a |workurl= would be handy. --{{victar|talk}} 05:34, 11 January 2019 (UTC)

You're supposed to use |url=. — SGconlaw (talk) 05:46, 11 January 2019 (UTC)

@Sgconlaw: I know I can use |url=, but I'd like define URLs for both |title/entry= and |work=. --{{victar|talk}} 05:56, 11 January 2019 (UTC)

I think the idea is that editors are supposed to be able to link the work name to an appropriate Wikipedia article, e.g., "[[w:BuzzFeed|BuzzFeed]]" or "{{w|BuzzFeed}}", which is why that parameter doesn't take an external link. Can you give an example of when you would want to create separate external links for both |title/entry= and |work=? — SGconlaw (talk) 06:29, 11 January 2019 (UTC)

@Sgconlaw: Sure. In {{R:unm:LTD}}, I'd like to give a link to the homepage for |work= and a link to the specific entry for |title/entry=. --{{victar|talk}} 06:41, 11 January 2019 (UTC)

So doesn't using |url= suffice in this case, as you've done? Just wondering what's the particular benefit of linking the entire work title to an external link. Then we'll have some references that use |url= and others that use |workurl=. — SGconlaw (talk) 08:08, 11 January 2019 (UTC)

@Sgconlaw: No, because as I pointed out, I'd like to have a link to the work, and another to the entry. The landing page of a work isn't always the root directory of homepage, so being able to direct people to the proper work url is useful. This, I imagine, also applies to journals in {{cite-journal}}. --{{victar|talk}} 08:38, 11 January 2019 (UTC)

@Victar: Ah, I just remembered that some time in the past a decision was made to link |url= to |entry= if the latter parameter is specified. This makes the {{cite}} templates work differently from the {{quote}} templates like |quote-book=, which have a separate |chapterurl= parameter. What I will do is to create a parameter called |entryurl= (or something similarly named). If that parameter is present then it will be linked to |entry=; if not, then the template will use |url=. I'll look into it in about three or four hours' time. — SGconlaw (talk) 10:45, 11 January 2019 (UTC)

@Victar:  Done, I have added |entryurl= (and, for some templates, |titleurl=) to {{cite-book}}, {{cite-journal}} and {{cite-web}}. — SGconlaw (talk) 17:40, 11 January 2019 (UTC)

Awesome, thanks, @Sgconlaw! --{{victar|talk}} 17:59, 11 January 2019 (UTC)

• @Sgconlaw, I'm not sure if this bug is related to changes made for the above, but I can no longer start |entry= with * without triggering bullet points. --{{victar|talk}} 07:46, 17 January 2019 (UTC)

  It's possible, because I relocated an opening quotating mark to avoid having to repeat it. I suggest surrounding the asterisk with <nowiki> tags. Also, in what situations would an entry start with an asterisk? — SGconlaw (talk) 07:50, 17 January 2019 (UTC)

  @Sgconlaw, using <nowiki> is not a practical solution as asterisks are commonly found in entry names of reconstructions. Here is an example of the bug manifesting. --{{victar|talk}} 08:24, 17 January 2019 (UTC)

  OK, I'll tweak the template later when I'm free. — SGconlaw (talk) 08:31, 17 January 2019 (UTC)

  @Victar:  Done. I think it's now fixed. — SGconlaw (talk) 18:26, 17 January 2019 (UTC)

  @Sgconlaw: Thanks! --{{victar|talk}} 18:29, 17 January 2019 (UTC)

• @Sgconlaw, what am I doing wrong here with |titleurl=? --{{victar|talk}} 23:52, 17 January 2019 (UTC)

  “Cite-book” doesn’t use |titleurl=. Just use |url=. — SGconlaw (talk) 01:43, 18 January 2019 (UTC)

  @Sgconlaw: If I use |url= it adds the link to |entry=, not |title=. Is there any way around that? --{{victar|talk}} 02:09, 18 January 2019 (UTC)

  Not at the moment, as the template doesn't envisage this scenario. If you use |entryurl= together with |url=, then |url= displays an external link next to the title. But if you use |url= alone, it assumes you want to link that to the value of |entry=. That was a choice made some years back; if we now want to change how the template works and force the use of |entryurl=, we'll need to identify all the templates that will be affected. — SGconlaw (talk) 03:04, 18 January 2019 (UTC)

  @Sgconlaw: What about adding |titleurl= which always displays an external link next to the title? --{{victar|talk}} 03:30, 18 January 2019 (UTC)

  I guess I can just do this. Problem solved. --{{victar|talk}} 04:47, 18 January 2019 (UTC)

  Oh, yeah ... — SGconlaw (talk) 06:18, 18 January 2019 (UTC)

Two lines calling same parameter

There seem to be two lines calling the same parameter:

|url = {{{url|{{{5|}}}}}}

|page = {{{page|{{{5|}}}}}}

There is an easy work-around, which is to use either url= or page= in the fifth slot, but perhaps this should be sorted? Cnilep (talk) 02:00, 3 July 2019 (UTC)

Hi, @Cnilep: thanks for pointing out the issue. I've updated the template so that |5= is only a synonym for |url=, as the template instructions indicate. — SGconlaw (talk) 03:32, 8 July 2019 (UTC)

Link to Wiktionary:Reference templates in See also

It would be helpful for people to be told that there are also website-specific templates. Akeosnhaoe (talk) 19:48, 19 April 2021 (UTC)

RFC discussion: January 2021

The following discussion has been moved from Wiktionary:Requests for cleanup (permalink).

This discussion is no longer live and is left here as an archive. Please do not modify this conversation, but feel free to discuss its conclusions.

---

Template:cite-web

• {{cite-web|author=Patrick M. Owens|title=Silva (old)|url=https://neolatinlexicon.org/|work=Neo-Latin Lexicon|publisher=Patrick M. Owens|nodate=yes}}

in feretrum displays as:

• Patrick M. Owens “Silva (old)”, in Neo-Latin Lexicon‎^[2], Patrick M. Owens

That is, even though it's "|nodate=yes", there's "(Can we date this quote?)".
"|date=no", to answer the question, doesn't fix it. --幽霊四 (talk) 23:23, 24 January 2021 (UTC)

• You can add accessdate. {{cite-web|accessdate=January 24, 2021|author=Patrick M. Owens|publisher=Patrick M. Owens|title=Silva (old)|url=https://neolatinlexicon.org/%7Cwork=Neo-Latin Lexicon}} => Patrick M. Owens (accessed January 24, 2021), “Silva (old)”, in Neo-Latin Lexicon‎^[3], Patrick M. Owens Vox Sciurorum (talk) 23:48, 24 January 2021 (UTC)

Then you would need to look through the history to find out when it was added and (likely) accessed? Plus, I don't think it's that good: ".. Owens (accessed ..)" - has he accessed it? was he accessed? --幽霊四 (talk) 13:59, 25 January 2021 (UTC)

@幽霊四: no, the accessdate is that date when you accessed it. Otherwise there is no indication of when the website was visited. — SGconlaw (talk) 16:26, 25 January 2021 (UTC)

feature request: DOI parameter

Can we get a doi= named parameter in this template? There are academic resources online with DOI that are not journal articles or books and I had to “hack around” the lack of DOI in {{cite-web}} recently when referencing such a thing in etymology of Old Irish Goídelc (see →DOI, it’s an online video lecture + PDF file with slides). // Silmeth ^@talk 20:21, 14 February 2024 (UTC)

@Silmethule: OK.  Done. — Sgconlaw (talk) 13:16, 15 February 2024 (UTC)

Incorrect urlencode if title is omitted

@JeffDoozan, it seems that this template is now double-urlencoding if the title is omitted, so the links to Trésor de la langue française informatisé on articles such as fainéant are currently broken.

Example:

{{cite-web|entryurl=https://www.cnrtl.fr/definition/{{urlencode:fainéant}}|entry=asdf|work=Trésor de la langue française informatisé}}

gives an incorrect, double-url encoded:

“asdf”, in Trésor de la langue française informatisé, (Can we date this quote?)

while if we include a title:

{{cite-web|entryurl=https://www.cnrtl.fr/definition/{{urlencode:fainéant}}|entry=asdf|title=asdfas|work=Trésor de la langue française informatisé}}

we get a functional link:

“asdf”, in “asdfas”, in Trésor de la langue française informatisé, (Can we date this quote?)

--130.208.182.103 12:59, 13 April 2024 (UTC)

Thanks for the ping, 130. @Benwing2 Do you have any thoughts on the best way to handle this? I don't see where in Module:quote any url escaping is being done, but it must be happening before make_chapter_with_url, which just generates a bare link with the value of the chapter name and title. Since quote-book also exhibits the double-escaping behavior, it seems like most of our links must already be in an unescaped format and I'm tempted to just rip out all the manual calls to {{urlencode}} in the R: templates. As a very temporary workaround, to avoid having broken links while this gets fixed, I added a check to the cite- template handling that falls back to the old template if entryurl, chapterurl, or titleurl contain "%"

Tests

Bare link with escaped url

foo

quote-book with escaped url

(Can we date this quote?), “foo”, in bar:

JeffDoozan (talk) 14:43, 13 April 2024 (UTC)

@JeffDoozan The double encoding is happening in the call to embedded_language_links() on line 575, which seems to URL-encode any % signs occurring in the text passed in. I remember running into this issue before; it's related to some changes made several months ago by User:Theknightwho to the code in Module:links, but I'm not sure exactly why the URL-encoding is happening there. You might want to ask Theknightwho. The reason this doesn't happen when a title is specified is in that case the pcall() fails (I'm not sure why), and it falls back to the old template code. IMO you should verify whether everything works fine if the URL is passed in raw, and if so, just rip out the URL encoding in the template. Benwing2 (talk) 20:29, 13 April 2024 (UTC)

@Benwing2: I was surprised that this isn't blowing up quote-book urls everywhere, but it turns out that pageurl isn't affected:

(Can we date this quote?), “bad link”, in bar, page good link:

|title= and |entry= are aliases in the -web templates, so specifying both generates and error that causes it to fall back to the old template. Ripping out the URL encoding in the templates would have the unintended consequence of passing unescaped spaces as part of the url, which currently generates an error. JeffDoozan (talk) 20:56, 13 April 2024 (UTC)

@Theknightwho As Ben mentioned, this seems to be caused by text = text:gsub("%%", "%%25") at Module:links#L-538. What's the reasoning behind escaping % in the links passed to embedded_language_links()? If it's for inter-wiki links or something, could we add a check for "://" to avoid mangling external URLs? JeffDoozan (talk) 23:00, 13 April 2024 (UTC)

@JeffDoozan I have fixed this by not calling embedded_language_links() unless there are embedded links. Note that this will run into issues if there are embedded links inside of the display portion of an external link. I verified this is possible, e.g. foobar; however, this should occur very rarely, and in any case I'm not sure it will continue to work if the raw embedded links are wrapped in HTML tags, as would happen using embedded_language_links(). Benwing2 (talk) 04:13, 14 April 2024 (UTC)

It's working as expected now, thank you for the fix. JeffDoozan (talk) 22:29, 14 April 2024 (UTC)

@Benwing2 @JeffDoozan Sorry for the delay on this - I've been putting it off, but I've started a (gradual) refactor of Module:links, which should deal with issues like this. It's not going to be anything revolutionary, but I don't think it's going to be possible to do anything more ambitious without untangling the spaghetti, as it's too unpredictable at the moment. Theknightwho (talk) 06:14, 19 April 2024 (UTC)

@Theknightwho Thanks. How much refactoring will you do (i.e. how much spaghetti untangling) and do you have any timeline? Benwing2 (talk) 06:35, 19 April 2024 (UTC)

@Benwing2 I'd like to keep the general structure the same for the time being, as that should keep things relatively stable. No timeline - I'd hope no more than a couple of weeks, but I won't be rolling it out all at once. Theknightwho (talk) 06:39, 19 April 2024 (UTC)

@Benwing2 If you look at the changes I made to the local function handle_redundant_wikilink, that should give you an idea of the level of refactoring I'm talking about: it's been completely rewritten, but it still does the same thing. Theknightwho (talk) 06:41, 19 April 2024 (UTC)

@Theknightwho OK cool, sounds good. Benwing2 (talk) 06:56, 19 April 2024 (UTC)

@Benwing2 One last thing: you've probably noticed this, but my biggest priority is optimising for speed, which sometimes comes at the expense of concise code (e.g. I just converted text:find("%[%[.-%]%]") to two find calls for "[[" and "]]" with the plain flag set). These kinds of micro-optimisatons do seem to make a genuine difference if you apply enough of them (and are pretty much the only reason the template parser is viable at all), and I think they're badly needed in Module:links and Module:languages, given how much they're called. I'll make sure to comment anything that seems weird/unintuitive (e.g. it's not obvious that if not match(text, "^()%[%[") is the fastest way to check if sub(text, 1, 2) ~= "[["). Theknightwho (talk) 07:52, 19 April 2024 (UTC)

@Theknightwho Yes, makes sense and please do comment anything that's not obvious, to avoid the problem of "tribal knowledge" that isn't written anywhere. Benwing2 (talk) 08:07, 19 April 2024 (UTC)