This is an archive of past discussions. 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 30 | Archive 31 | Archive 32 | Archive 33 | Archive 34 | Archive 35 | → | Archive 40 |
I wanted to bring this topic back to the surface again. It was recently discussed at Help_talk:Citation_Style_1/Archive_30#PMC, which led to the creation of phab:T157152. This ticket concludes (and I agree) that what CS1 is doing is basically not following the guidelines for usage of PMCID usage. It is therefor a 'CS1'-problem that we should deal with at this level as well. I think we have two options, either make the 'input format' of the PMCID be more flexible (The lua code can easily be adapted to accept both) or cleanup PMCID additions with a bot. — TheDJ ( talk • contribs) 15:14, 12 April 2017 (UTC)
(The lua code can easily be adapted to accept both)Do we want to have output of "PMC PMC\d*" or "PMC \d*" in the event that we take that path? -- Izno ( talk) 15:59, 12 April 2017 (UTC)
|pmc=PMC2291284
).
Boghog (
talk) 17:31, 12 April 2017 (UTC)
|volume=volume298
, |issue=issue1
, |pages=pages59–70
, |year=year2006
, |doi=doi10.1016/j.ydbio.2006.06.013
, |volume=volume4
}. The context is provided by the parameter name (e.g., |pmc=2291284
) and in wiki link in the rendered citation (
PMC:
2291284). It is redundant to repeat the parameter name in the parameter value and the wiki linked database name in the database accession number.
Boghog (
talk) 19:46, 13 April 2017 (UTC)the actual PMID is a pure number: e.g. 18183754Just quoting you ;-) Boghog ( talk) 20:37, 13 April 2017 (UTC)
The most valuable of all talents is that of never using two words when one will do.
{{
cite book}}
: Check |pmc=
value (
help){{
cite book}}
: Check |pmc=
value (
help){{
cite book}}
: CS1 maint: PMC format (
link){{
cite book}}
: Check |pmc=
value (
help)|pmc=pmc1234
and |pmc=PMC1234
in addition to the existing |pmc=1234
(do we need to allow |pmc=pmc 1234
too?), and leave the rendered display as-is. If there is a desire to change the rendered display, that's a separate matter (I am also of the view that the PubMed guidelines seem to want redundancy that we are not required to show; broadly I think they want any display to be clear whether the number is a PMID or a PMC, which we do clearly as is, so I don't see a need to change rendered display.)
Rjwilmsi 19:21, 12 April 2017 (UTC)
|doi=
, |pmid=
, |isbn=
, |issn=
, |bibcode=
, etc are rendered.
Boghog (
talk) 09:34, 14 April 2017 (UTC)
|url=
, we don't put a link to the Wikipedia article for the website, and that's fine! As far as I know, Wikipedia is the only website with this weird convention. Citation templates are meant to refer to a source, not to give a lecture on the IT infrastructure of scholarly communications, especially when it comes to the cost of a painful redundancy like "PMC PMC1234". −
Pintoch (
talk) 12:27, 14 April 2017 (UTC)
No one has proposed to write PMC twice.The NIH format writes PMC twice (PMCID: PMC012345). Boghog ( talk) 13:29, 14 April 2017 (UTC)
|pmid=
.
Boghog (
talk) 16:21, 14 April 2017 (UTC)
|pmc=pmc1234
(or |pmcid=pmc1234
if you prefer) that's fine, but please make sure the string "PMC" does not appear twice in the output (just to make things clear: in "PMCID: PMC1234", there are two occurrences of the "PMC" string). −
Pintoch (
talk) 17:58, 14 April 2017 (UTC)Anyone submitting an application, proposal or report to the NIH. Wikipedia is not submitting anything to the NIH. The guideline is silent about how references or links to PMC are formatted in journals. This is a decision made by individual journals, not the NIH. Likewise Wikipedia is not bound by NIH guidelines. Boghog ( talk) 09:45, 14 April 2017 (UTC)
In the interest of maintaining our citation style while allowing editors to add PMC identifiers that are technically correct, and in the interest of avoiding redundancy, I propose the following change, if it is technically possible:
|pmc=1234567
and |pmc=PMC1234567
and |pmc=pmc1234567
.|pmc=PMC12345
back to |pmc=12345
internally, and then display it as usual. In that sense, it is correct to say that the code "drops the pmc from the identifier" (even if "
PMC: " is prepended afterwards). By doing so it keeps the rendered version unchanged. I think the description above is crystal clear for anyone familiar with CS1, which is your case. −
Pintoch (
talk) 00:05, 15 April 2017 (UTC)https://www.crossref.org/display-guidelines/ suggests that we link to https://doi.org/10.nnnn/xxx.xxx, dropping the "dx." portion of the fully qualified domain name. I suggest that we make this minor, non-urgent change to the Module sandbox after this weekend's update. – Jonesey95 ( talk) 22:28, 25 April 2017 (UTC)
How to note a reprint? bkb ( talk) 08:44, 17 April 2017 (UTC)
|edition=
or |type=
.|edition=Reprint
usually.
Headbomb {
t ·
c ·
p ·
b} 11:23, 17 April 2017 (UTC)
|print-run=
a while ago. This would allow editors to specify the extra info where they see fit without overloading the |edition=
parameter. For now, the template could just concatenate the values of both parameters for output, but keeping it in separate parameters would improve machine readability and allow us to adjust the output format depending on the target environment anytime later on (f.e. ignore the |print-run=
parameter for meta data schemes not supporting it).The CS1 templates are happy with |date=July–August 2008
but give warnings for the should-be-identical |date=July–August 2008
. There are some editors out there (not me, but others I've interacted with) who insist that spelling out the – rather than using an en-dash character is necessary to make the type of dash more visible to editors reading the source. Is there some way to make the citation templates accept input in this format? —
David Eppstein (
talk) 19:49, 16 April 2017 (UTC)
{{
spaced ndash}}
resolves to:
– 
|date=Winter 1992{{spaced ndash}}Spring 1993
Winter 1992 – Spring 1993
Winter+1992%26nbsp%3B%26ndash%3B%26%2332%3BSpring+1993
That is why {{ spaced en dash}} (a correct implementation) throws a hiccup. {{ en dash}} doesn't because it utilizes the plain glyph. Symbolically/programmatically, {{ en dash}} is inferior: the rendering of glyphs is not uniform.
the rendering of glyphs is not uniform.
{{spaced en dash}}{{en dash}}
– –
 – –
–
maps to the unicode character U+2013 and has done since html 4 and perhaps earlier. See
html5 named character references (a rather awful table –
here's a friendlier version). For the purposes of display, there is no distinction between a source that uses –
or –
or the en dash glyph. The browser will render any of these characters in exactly the same way according to the specified font (if it doesn't then the browser is fundamentally flawed).Wikipedia serves html5 using character set UTF-8. In html5, –
maps to the unicode character U+2013
. Because –
is defined as U+2013, any browser compliant with html4 and later will render –
and U+2013 in the same way. How you see that character is determined by your chosen font. I can set my browser to render all text in a serif font which may display an en dash differently from the way it would be display were I to set my browser to render all text with a sanserif font. At the source level, there is no ambiguity because –
= U+2013.bad/lazy template authoring.I don't understand why you have made that statement.
So all these years busybodies have been giving people a hard time for using templates in citation values for nothing? I'm shocked. E Eng 01:04, 22 April 2017 (UTC)
I'm looking at Template:Cite speech/doc and it seems to me that the location parameter is ambiguous in meaning. I believe Module:Citation/CS1 understands it as the place of publication, but one of the examples given is this:
On the one hand, I suppose I'm requesting that the documentation be clarified. On the other, I wonder if Module:Citation/CS1 needs to be updated to be able to include the actual location of the speech and event, which seems like an appropriate thing to include in a citation for an unpublished speech, if not for all speeches. Sondra.kinsey ( talk) 23:09, 28 April 2017 (UTC) PS. Please use {{ reply to}}; I don't watch this page.
|publication-place=
and a |location=
. Cite speech might reasonably make use of both. That said, you should
WP:SAYWHEREYOUGOTIT--so I am not entirely sure about your use case. Maybe you can provide the specific citation you have in mind. --
Izno (
talk) 13:08, 29 April 2017 (UTC)Presumably, the CS1 errors in the "How the templates work" section were unintended and undesired.
Here, I've removed the |date=Date
part of the wikitext for the example citations to get rid of them. Improve as needed, please.
Wtmitchell
(talk) (earlier Boracay Bill) 02:24, 30 April 2017 (UTC)
|date=n.d.
and added a note below the examples. That may need refinement though.
Imzadi 1979
→ 05:13, 30 April 2017 (UTC)
This discussion begat
this series of edits to
Module:Citation/CS1/Whitelist/sandbox wherein |ARXIV=
and |BIBCODE=
were deprecated. Those changes went live on 29 October 2016. In the interim I think that support for the now long-deprecated parameters should have been removed from the whitelist sandbox and from
Module:Citation/CS1/Configuration/sandbox. That did not happen.
Rather than add these parameters to the help documentation (they never were) and wait for the next update and because they do not appear be in use anywhere (none were in Category:Pages containing cite templates with deprecated parameters at the time that it was emptied), without objection, tomorrow I shall mark them as unsupported in Module:Citation/CS1/Whitelist and Module:Citation/CS1/Configuration.
We still have |version=
marked as deprecated when it is used with {{
cite arxiv}}
(deprecated since 25 July 2015). This too, I shall mark as unsupported in Module:Citation/CS1/Whitelist. More complex changes to
Module:Citation/CS1 are also needed but can be deferred to the next update.
— Trappist the monk ( talk) 13:03, 29 April 2017 (UTC)
Done. The changes to Module:Citation/CS1 were not so complex as I imagined so that has been done also.
— Trappist the monk ( talk) 09:44, 30 April 2017 (UTC)
Now that |coauthors=
is unsupported, we should be able to delete
Category:CS1 errors: coauthors without author, I believe. Do we need code changes to the module, or can we just delete the category? –
Jonesey95 (
talk) 13:38, 30 April 2017 (UTC)
The template commons:Template:Cite_journal on Wikimedia Commons does not have implemented parameters first1= |last1= |first2= |last2= etc. commons:Template talk:Cite journal#Parameters. Could you improve it, please? This is crucial for proper referencing of images. Thanks. -- Snek01 ( talk) 18:51, 1 May 2017 (UTC)
There is a metadata bug. Somehow, some of the multiple bytes of unicode characters outside of the ascii character set are not all included in the metadata:
{{cite book |title=Я}}
produces this metadata for the title:
&rft.btitle=%D0%AF
– correctand:
{{cite book |title=ש}}
&rft.btitle=%D7%A9
– correctbut:
{{cite book |title=魂}}
&rft.btitle=%E9%82
– should be: %E9%AD%82
and:
{{cite book |title=–}}
&rft.btitle=%93
– should be: %E2%80%93
From these simple examples, it would appear that something is buggering up three-byte unicode percent encoding. This problem was apparently noticed just after the 29–30 April 2017 update to the live module suite. I am at a loss to explain this problem as a result of the changes that were incorporated in the update. So, I have reverted the sandboxen to the last live version before the update. Let me repeat that:
After reverting to the last live version, the simple tests above produce the same results.
The modules use the function mw.uri.encode()
to percent-encode metadata and also to encode identifiers like |doi=
. If I make up a doi with a character that doesn't work in the metadata, the doi link is encoded correctly:
{{cite book/new |title=Title |doi=10.1234/.魂}}
//dx.doi.org/10.1234%2F.%E9%AD%82
From all of this, I know that the problem has been with us for some time and that the problem appears to be confined to the metadata. Now it is just a matter of locating it.
— Trappist the monk ( talk) 15:19, 2 May 2017 (UTC)
value = value:gsub ('[\226\128\141\226\128\139\194\173]', '')
value = mw.ustring.gsub (value, '[\226\128\141\226\128\139\194\173]', '');
\226\128\141
for zero-width joiner, etc.value
is an en dash, its byte values are \226\128\93
. In the original version, value:gsub()
finds both the \226
and the \128
bytes and removes them leaving the \147 which is later percent encoded to %93. Similarly, 魂 has byte values of \233\173\130
, value:gsub() finds and removes the \173
leaving behind \233\130
which percent encodes to %E9%82
.{{cite book |title=魂}}
'"`UNIQ--templatestyles-00000027-QINU`"'<cite class="citation book cs1">''魂''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=%E9%AD%82&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+33" class="Z3988"></span>
value = value:gsub ('\226\128\138', ' ');
value = value:gsub ('[\009\010\013]', ' ');
value
must match exactly. In the second, like regex, the pattern is a set of three individual bytes so will match with any of the three single-byte characters horizontal tab, line feed, or carriage return.Re: "boxen". Yes, a hacker in-joke, but it has appeared in a headline in a reliable source at least once. It appears in article space with an explanation in a few places, and there's Pizza boxen (a redirect); I agree with David Eppstein that it should not be used casually in article space. – Jonesey95 ( talk) 20:22, 2 May 2017 (UTC)
When User:SpikeToronto recently made this edit and many similar ones, trying to improve the table format for iPads, it actually broke the format for an ordinary Chrome browser on a Windows laptop. For example, unless the browser window is extremely wide, the right side of the table in Template:Cite book/doc#TemplateData gets truncated, cutting off words and the column-sort arrows, with no horizontal scrollbar to reach the truncated content. Is there a way to make these tables work properly on both types of devices? — Patrug ( talk) 07:22, 3 May 2017 (UTC)
{{
TemplateData}}
which, I gather has the job of rendering the TemplateData table.{{
TemplateData}}
doesn't have the job of rendering the TemplateData table.Can a new maintenance category be created (and coded into
Module:citation/CS1) for when Archived copy
is used as a title in a cite-template? Currently we have 38 000+ articles (
insource:/\|title\=Archived copy/), and I bet that not a single one of them should use that as a title. (
t)
Josve05a (
c) 14:48, 29 April 2017 (UTC)
|work=
Wayback Machine
& |work=Wayback Machine
--(
t)
Josve05a (
c) 15:16, 29 April 2017 (UTC)
|title=Archived copy
.
72.43.99.146 (
talk) 12:44, 4 May 2017 (UTC)Hi, I was wondering why the volume and page numbers were separated so much in
Template:Cite encyclopedia? Right now the volume separated from the pages by the edition, publishing location, and publishing house. Should I be using |at=
instead so that the volume of the encyclopedia immediately precedes the page numbers, as in Chicago or APA?
Because right now I think it's unclear to have the volume so far from the pages as in:
{{
cite encyclopedia}}
: |last1=
has generic name (
help)I would expect it to be something like:
{{
cite encyclopedia}}
: |last1=
has generic name (
help)Thanks. Umimmak ( talk) 15:39, 8 May 2017 (UTC)
A primary goal when we integrated all of the old wikitext cs1|2 templates into the new Lua
Module:Citation/CS1, was to make the new look like the old. Apparently we were successful with the |volume=
/ |page(s)=
aspect of that integration for {{
cite encyclopedia}}
:
Wikitext | {{cite encyclopedia
|
---|---|
Live | Author, A. (2017). "Entry". In Editor, E. (ed.). Title of Encyclopedia. Vol. 3 (2nd ed.). City: Publishing House. pp. 100–102. {{
cite encyclopedia}} : |last1= has generic name (
help)
|
Sandbox | Author, A. (2017). "Entry". In Editor, E. (ed.). Title of Encyclopedia. Vol. 3 (2nd ed.). City: Publishing House. pp. 100–102. {{
cite encyclopedia}} : |last1= has generic name (
help)
|
The rendering of {{cite encyclopedia}}
looks much like the rendering of {{
cite book}}
given similar parameters:
{{cite book |last1=Author|first1=A.|date=2017|chapter=Chapter |title=Title of Book |edition=2nd|editor-last=Editor|editor-first=E.|volume=3|pages=100–102|publisher=Publishing House|location=City}}
If you are concerned, you might research the issue in the archives of this talk page and the archives of the {{cite encyclopedia}}
talk page. There may be something there that will explain why the original authors of {{cite encyclopedia}}
did what they did. Or not.
Contructs like this:
|at=Vol. 3, {{pp.|100|102}}
are discouraged because it introduces volume information into an in-source element of the metadata.
— Trappist the monk ( talk) 16:15, 8 May 2017 (UTC)
|page=
, |pages=
, and |at=
are
in-source location parameters; all map to a key called &rft.pages
; volume information does not belong there. There is a cs1|2 parameter specially intended to hold volume information: |volume=
which feeds &rft.volume
.|page=
.
Umimmak (
talk) 20:35, 8 May 2017 (UTC)I recently had a FAR where a user pointed out I was using a Japanese book and that I needed to provide both the original Japanese prose of the book's information and the English translation. Would it be "quote=Japanese and trans_quote=English"? Regards, Tintor2 ( talk) 00:08, 5 May 2017 (UTC)
|quote=Japanese quote</q> <q>[English quote]
– the </q> <q>
are used here because the quotation marks around |quote=
are formed that way
Japanese quote.
[English quote.]
... ています</q> <q>Hoshino: Guess ...
</q>
following the original language quote closes the opening <q>
provided by the template. Similarly, the <q>
preceding the English translation matches the closing </q> provided by the template. And thus, all is in balance.|trans-quote=
parameter (some while ago). This would be following the basic principle to keep different types of contents in different parameters.|quote=
and |trans-quote=
we'd be free to change the output format whenever this might become necessary in the future, even depending on settings or target devices. We might even suppress the translation if it would not be desired in a certain context. Example:<ref>{{citation|...}}. "ています" is translated [by whom?] as "Hoshino: ...".</ref>
|trans-quote=
parameter which explains why it did not work.I agree putting a quotation inside a citation template is probably a bad idea. One reason it's a bad idea is quotations might need all kinds of special stuff to reproduce what's in the source, like a table for instance. Such complex markup would be very likely to break the citation template.
However, I disagree that a quote from a source should either be placed in the running text of the article, or omitted. Most citations in Wikipedia are in the form of an endnote. Endnotes are for details that distract from the point being made in the running text of the article. Such detailed digressions might very well need quotations from the source. Thus, there's nothing wrong with including quotes from the source in a footnote. Jc3s5h ( talk) 12:54, 6 May 2017 (UTC)
a source should either be placed in the running text of the article, or omitted; I made no mention of
running text. Do not put words into my mouth that I have not spoken. By
put the quote in the article and cite it, I simply meant that the quotation, if required, should be placed somewhere other than in the citation itself.
third opinion. Clarify?
|quote=
at
WT:Verifiability#How does one transparently cite more than one part of an e-book in a single citation?: to provide a short piece of text that can be searched for to locate the section referenced in media such as certain e-books that do not have pagination or other in-source indices. But even that can be handled outside of the template. ~
J. Johnson (JJ) (
talk) 20:27, 8 May 2017 (UTC)Please see/join this discussion about a bot conversion of some existing reference lists making use of unordered lists (*) instead of definition lists (:). — TheDJ ( talk • contribs) 14:07, 12 May 2017 (UTC)
I can't see a field for a subtitle. Is this a deliberate policy decision or an omission? -- Pfold ( talk) 11:53, 6 May 2017 (UTC)
|subtitle=
parameter. Most often, if a subtitle is required, it is included in |title=
set off from the main title with a colon:
|title=Main Title: Subtitle
|subtitle=
is a policy decision or an omission. You might troll through the archives of this page, the talk page archives of the individual templates before they were merged into this page, and the talk page archives for {{
citation}}
.|sub-title=
(or similar) parameter. I would welcome its introduction in the English Wikipedia as well. --
Matthiaspaul (
talk) 00:14, 14 May 2017 (UTC)|title-separator=
parameter could be used to specify it, otherwise the template would default to some internal default like " - ".|title-link=
and |url=
. In this case, our templates throw an error message, as there is only one string to attach the link to. |sub-title=
could help remedy this situation, as the second link could be attached to the sub-title then - not a perfect solution, but still better than having to append raw links after the citation.{{
cite journal}}
: Check |issn=
value (
help); Invalid |ref=harv
(
help)That ISSN resolves to the correct title, yet the template flags it as problematic. What gives? Headbomb { t · c · p · b} 12:04, 15 May 2017 (UTC)
{{issn|1225-8989}}
The visual design RFC for the access locks concluded with an essentially 50-50 split community on the colour of the "free with conditions" lock (yellow vs blue). This RFC is to investigate support for a third option (grey). Headbomb { t · c · p · b} 14:55, 22 April 2017 (UTC)
The paste options were 1&2
People who supported this cited the intuitiveness of the traffic light colour scheme, people who opposed it mostly cited the yellow not being very yellow, and the colourblind-friendlier blue.
People who supported this cited the yellow not being very yellow in the previous scheme, and the colourblind-friendlier blue. People who opposed this cited the lack of a recognizable colour scheme of any sort. It also tends to get lost in a sea of blue. This had marginally more support (1 more !vote out of 22 or so).
However, late in the RFC, an alternate colour scheme was proposed as an alternative and garnered some support, but it was too late in the RFC to be introduced an option. Let's consider it now.
This has neither drawback of schemes 1 & 2. Green/Grey/Red is an intuitive colour scheme, is just as colourblind friendly as Green/Blue/Red, and doesn't get as lost in the sea of blue as the blue one does. I'd have included arguments against grey, but I know of none.
Basically, how this would look is something like
Support #3 as proposer. Headbomb { t · c · p · b} 14:55, 22 April 2017 (UTC)
Oppose all. See below. – Finnusertop ( talk ⋅ contribs) 01:46, 6 May 2017 (UTC)
I do not know whether this is the proper procedure, considering that the referenced RFC was submitted at a much better attended forum. At best, imo whatever discussion results here, should be used to stage a proper RFC at the proper forum. Especially since the original RFC seems inconclusive on the related issues. 65.88.88.126 ( talk) 20:56, 22 April 2017 (UTC)
Hey All; at the WMF we have been working with OCLC to make ISBN generated citations available, through using their ISBN database. We have deployed the feature on all language Wikipedias: you can learn more about it on the Wikimedia blog. Astinson (WMF) ( talk) 19:29, 11 May 2017 (UTC)
|df=
for the first problem, if you don't simply want to use a script such as the one that
Ohconfucius provides. The WMF developer team is unwilling to let us get the dates in the format we wish. As for the second problem, using ISO dates allows for ambiguity in the form of 1993-00-00 to indicate that the year is known but not the month nor day, as well as 1993-01-00 to indicate that year and month are known, but not the day--I do not know why they use 01 instead. (It impacts Wikidata too, but I haven't thought to comment there yet.) --
Izno (
talk) 20:32, 11 May 2017 (UTC)
|location=Ljubljana
; the Gallery Citation left out both |location=
and |publisher=
.{{cite book|last1=Maps|first1=Peekaboo|title=Berkeley, Oakland : Albany, Emeryville, Alameda, Kensington|date=2009|publisher=Peek A Boo Maps|location=[Berkeley?]|isbn=9783161484100|edition=1st ed.}}
{{
cite book}}
: |edition=
has extra text (
help)|citoid=
) which when equal to oclc
, creates a green maintenance category message with some text of the sort: "CS1 maintenance: Citations imported from
OCLC", if we believe that OCLC is so poor a quality of reference and that no-one will go back to fiddle with parameters. For reference, I know I use Citoid now for other websites and its hit-or-miss-enough in general such that I always check the imported citation, so I'm not sure if such a parameter is even necessary, since I would guess most others who use the service have a similar workflow. --
Izno (
talk) 22:06, 12 May 2017 (UTC)On a related issue, Mediawiki's refusal to use any date format other than YYYY-MM-DD in their cites (because they don't want to go through the hassle of full internationalization): in response to this, we could always be passive-aggressive about it and modify the cite templates to put up big red edit-time warnings when they see dates in this format in the date field (not the accessdate where they are ok): "Warning: Numeric date format detected. Please convert all dates to the prevailing style of the article." Because unless the users of the citoid template see it as not properly working, they won't notice the work it causes the rest of us and won't be motivated to do anything about the problem. — David Eppstein ( talk) 16:30, 12 May 2017 (UTC)
For some reason I was under the impression that the "cite journal" would accept a "license" parameter where one could indicate, e.g., "CC BY". I do not see it. Is there any (other?) way to indicate this? — fnielsen ( talk) 12:39, 20 May 2017 (UTC)
Related to the discussions at Help_talk:Citation_Style_1#ISBNs_in_mw:Citoid and T132308.
Because WP:DATE does not allow year initial numeric dates in the form YYYY-MM but does allow YYYY–YY (with an en dash), and because cs1|2 emits an error when the MM or YY portion of those dates is in the range 00–12 inclusive, and because citoid needs to be able to transfer dates to all of the different language wikis, it has been suggested that citoid use the Extended Date/Time Format (EDTF). A draft of the standard is here.
For us, the immediate issue is the YYYY-xx date form. EDTF provides an alternate way to encode that kind of date. Similar in form to YYYY-MM-DD, EDTF allows for portions of the date string to be declared as 'unspecified'. When citoid needs to send en.wiki a month and year date, it can take the form |date=YYYY-MM-uu
. That date format would surely violate WP:DATE so needs to be transformed into a more appropriate form. I have hacked the module sandbox to accept and transform dates that are provided in this style:
{{cite book/new |title=Title |date=2000-06-uu}}
Similar to the transformations preformed for |df=
and for auto-changing hypens to dashes, if there are any date errors in the citation, even in unrelated parameters, the module will not do any transformations. Here, using the same format for |access-date=
, causes an error because |access-date=
requires a day:
{{cite web/new |url=//example.com |title=Title |date=2000-06-uu |access-date=2017-05-uu}}
— Trappist the monk ( talk) 16:45, 18 May 2017 (UTC)
In preparation for the WikiCite event, currently taking place in Vienna, I have built a demonstrator template, {{ Cite Q}}. Much work remains to be done, to deal with more complex use cases, and to resolve the issues listed there. Hopefully that will be addressed during the WikiCite hackathon, on Thursday (CET time, GMT +2). Your comments and remote participation will be welcome. Please use the template's talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:09, 23 May 2017 (UTC)
This
edit request to
Template:Cite web has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
I would like to make an edit request adding a new lastnamefirst parameter. It changes the name order in citations, defaulting to yes. Change it to no for Icelandic names. Numberguy6 ( talk) 15:54, 23 May 2017 (UTC)
{{
edit protected}}
template. This may be a valuable discussion to have but it certainly does not have a consensus at this time. What reason do you propose to make this change?
Izno (
talk) 16:13, 23 May 2017 (UTC)Is there a way in this family of templates to be able indicate the licensing of the cited material? I am particularly interested in being able to mark a citation as being Creative Commons licensed so that the reader can see if it can be re-used. As Wikipedians, we are generally in favour of information being open and reusable. While I can see that we support expressing whether a source is free/subscription/etc (which affects "open"), I cannot see a similar way of expressing the source's potential for re-use. As a writer of Wikipedia, I would love to be alerted to CC-licensed materials (particularly the ones that enable re-use on Wikipedia itself). I write a great deal about Queensland, Australia, and there are a lot of government resources that people don't realise are CC-BY licensed and I'd like to alert readers (and other writers) to this when citing them. Is there a way to do it? Or do I have to do it after the cite template and before the closing ref tag as I did at State Strategic Touring Route. Thanks Kerry ( talk) 08:18, 27 May 2017 (UTC)
This is an archive of past discussions. 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 30 | Archive 31 | Archive 32 | Archive 33 | Archive 34 | Archive 35 | → | Archive 40 |
I wanted to bring this topic back to the surface again. It was recently discussed at Help_talk:Citation_Style_1/Archive_30#PMC, which led to the creation of phab:T157152. This ticket concludes (and I agree) that what CS1 is doing is basically not following the guidelines for usage of PMCID usage. It is therefor a 'CS1'-problem that we should deal with at this level as well. I think we have two options, either make the 'input format' of the PMCID be more flexible (The lua code can easily be adapted to accept both) or cleanup PMCID additions with a bot. — TheDJ ( talk • contribs) 15:14, 12 April 2017 (UTC)
(The lua code can easily be adapted to accept both)Do we want to have output of "PMC PMC\d*" or "PMC \d*" in the event that we take that path? -- Izno ( talk) 15:59, 12 April 2017 (UTC)
|pmc=PMC2291284
).
Boghog (
talk) 17:31, 12 April 2017 (UTC)
|volume=volume298
, |issue=issue1
, |pages=pages59–70
, |year=year2006
, |doi=doi10.1016/j.ydbio.2006.06.013
, |volume=volume4
}. The context is provided by the parameter name (e.g., |pmc=2291284
) and in wiki link in the rendered citation (
PMC:
2291284). It is redundant to repeat the parameter name in the parameter value and the wiki linked database name in the database accession number.
Boghog (
talk) 19:46, 13 April 2017 (UTC)the actual PMID is a pure number: e.g. 18183754Just quoting you ;-) Boghog ( talk) 20:37, 13 April 2017 (UTC)
The most valuable of all talents is that of never using two words when one will do.
{{
cite book}}
: Check |pmc=
value (
help){{
cite book}}
: Check |pmc=
value (
help){{
cite book}}
: CS1 maint: PMC format (
link){{
cite book}}
: Check |pmc=
value (
help)|pmc=pmc1234
and |pmc=PMC1234
in addition to the existing |pmc=1234
(do we need to allow |pmc=pmc 1234
too?), and leave the rendered display as-is. If there is a desire to change the rendered display, that's a separate matter (I am also of the view that the PubMed guidelines seem to want redundancy that we are not required to show; broadly I think they want any display to be clear whether the number is a PMID or a PMC, which we do clearly as is, so I don't see a need to change rendered display.)
Rjwilmsi 19:21, 12 April 2017 (UTC)
|doi=
, |pmid=
, |isbn=
, |issn=
, |bibcode=
, etc are rendered.
Boghog (
talk) 09:34, 14 April 2017 (UTC)
|url=
, we don't put a link to the Wikipedia article for the website, and that's fine! As far as I know, Wikipedia is the only website with this weird convention. Citation templates are meant to refer to a source, not to give a lecture on the IT infrastructure of scholarly communications, especially when it comes to the cost of a painful redundancy like "PMC PMC1234". −
Pintoch (
talk) 12:27, 14 April 2017 (UTC)
No one has proposed to write PMC twice.The NIH format writes PMC twice (PMCID: PMC012345). Boghog ( talk) 13:29, 14 April 2017 (UTC)
|pmid=
.
Boghog (
talk) 16:21, 14 April 2017 (UTC)
|pmc=pmc1234
(or |pmcid=pmc1234
if you prefer) that's fine, but please make sure the string "PMC" does not appear twice in the output (just to make things clear: in "PMCID: PMC1234", there are two occurrences of the "PMC" string). −
Pintoch (
talk) 17:58, 14 April 2017 (UTC)Anyone submitting an application, proposal or report to the NIH. Wikipedia is not submitting anything to the NIH. The guideline is silent about how references or links to PMC are formatted in journals. This is a decision made by individual journals, not the NIH. Likewise Wikipedia is not bound by NIH guidelines. Boghog ( talk) 09:45, 14 April 2017 (UTC)
In the interest of maintaining our citation style while allowing editors to add PMC identifiers that are technically correct, and in the interest of avoiding redundancy, I propose the following change, if it is technically possible:
|pmc=1234567
and |pmc=PMC1234567
and |pmc=pmc1234567
.|pmc=PMC12345
back to |pmc=12345
internally, and then display it as usual. In that sense, it is correct to say that the code "drops the pmc from the identifier" (even if "
PMC: " is prepended afterwards). By doing so it keeps the rendered version unchanged. I think the description above is crystal clear for anyone familiar with CS1, which is your case. −
Pintoch (
talk) 00:05, 15 April 2017 (UTC)https://www.crossref.org/display-guidelines/ suggests that we link to https://doi.org/10.nnnn/xxx.xxx, dropping the "dx." portion of the fully qualified domain name. I suggest that we make this minor, non-urgent change to the Module sandbox after this weekend's update. – Jonesey95 ( talk) 22:28, 25 April 2017 (UTC)
How to note a reprint? bkb ( talk) 08:44, 17 April 2017 (UTC)
|edition=
or |type=
.|edition=Reprint
usually.
Headbomb {
t ·
c ·
p ·
b} 11:23, 17 April 2017 (UTC)
|print-run=
a while ago. This would allow editors to specify the extra info where they see fit without overloading the |edition=
parameter. For now, the template could just concatenate the values of both parameters for output, but keeping it in separate parameters would improve machine readability and allow us to adjust the output format depending on the target environment anytime later on (f.e. ignore the |print-run=
parameter for meta data schemes not supporting it).The CS1 templates are happy with |date=July–August 2008
but give warnings for the should-be-identical |date=July–August 2008
. There are some editors out there (not me, but others I've interacted with) who insist that spelling out the – rather than using an en-dash character is necessary to make the type of dash more visible to editors reading the source. Is there some way to make the citation templates accept input in this format? —
David Eppstein (
talk) 19:49, 16 April 2017 (UTC)
{{
spaced ndash}}
resolves to:
– 
|date=Winter 1992{{spaced ndash}}Spring 1993
Winter 1992 – Spring 1993
Winter+1992%26nbsp%3B%26ndash%3B%26%2332%3BSpring+1993
That is why {{ spaced en dash}} (a correct implementation) throws a hiccup. {{ en dash}} doesn't because it utilizes the plain glyph. Symbolically/programmatically, {{ en dash}} is inferior: the rendering of glyphs is not uniform.
the rendering of glyphs is not uniform.
{{spaced en dash}}{{en dash}}
– –
 – –
–
maps to the unicode character U+2013 and has done since html 4 and perhaps earlier. See
html5 named character references (a rather awful table –
here's a friendlier version). For the purposes of display, there is no distinction between a source that uses –
or –
or the en dash glyph. The browser will render any of these characters in exactly the same way according to the specified font (if it doesn't then the browser is fundamentally flawed).Wikipedia serves html5 using character set UTF-8. In html5, –
maps to the unicode character U+2013
. Because –
is defined as U+2013, any browser compliant with html4 and later will render –
and U+2013 in the same way. How you see that character is determined by your chosen font. I can set my browser to render all text in a serif font which may display an en dash differently from the way it would be display were I to set my browser to render all text with a sanserif font. At the source level, there is no ambiguity because –
= U+2013.bad/lazy template authoring.I don't understand why you have made that statement.
So all these years busybodies have been giving people a hard time for using templates in citation values for nothing? I'm shocked. E Eng 01:04, 22 April 2017 (UTC)
I'm looking at Template:Cite speech/doc and it seems to me that the location parameter is ambiguous in meaning. I believe Module:Citation/CS1 understands it as the place of publication, but one of the examples given is this:
On the one hand, I suppose I'm requesting that the documentation be clarified. On the other, I wonder if Module:Citation/CS1 needs to be updated to be able to include the actual location of the speech and event, which seems like an appropriate thing to include in a citation for an unpublished speech, if not for all speeches. Sondra.kinsey ( talk) 23:09, 28 April 2017 (UTC) PS. Please use {{ reply to}}; I don't watch this page.
|publication-place=
and a |location=
. Cite speech might reasonably make use of both. That said, you should
WP:SAYWHEREYOUGOTIT--so I am not entirely sure about your use case. Maybe you can provide the specific citation you have in mind. --
Izno (
talk) 13:08, 29 April 2017 (UTC)Presumably, the CS1 errors in the "How the templates work" section were unintended and undesired.
Here, I've removed the |date=Date
part of the wikitext for the example citations to get rid of them. Improve as needed, please.
Wtmitchell
(talk) (earlier Boracay Bill) 02:24, 30 April 2017 (UTC)
|date=n.d.
and added a note below the examples. That may need refinement though.
Imzadi 1979
→ 05:13, 30 April 2017 (UTC)
This discussion begat
this series of edits to
Module:Citation/CS1/Whitelist/sandbox wherein |ARXIV=
and |BIBCODE=
were deprecated. Those changes went live on 29 October 2016. In the interim I think that support for the now long-deprecated parameters should have been removed from the whitelist sandbox and from
Module:Citation/CS1/Configuration/sandbox. That did not happen.
Rather than add these parameters to the help documentation (they never were) and wait for the next update and because they do not appear be in use anywhere (none were in Category:Pages containing cite templates with deprecated parameters at the time that it was emptied), without objection, tomorrow I shall mark them as unsupported in Module:Citation/CS1/Whitelist and Module:Citation/CS1/Configuration.
We still have |version=
marked as deprecated when it is used with {{
cite arxiv}}
(deprecated since 25 July 2015). This too, I shall mark as unsupported in Module:Citation/CS1/Whitelist. More complex changes to
Module:Citation/CS1 are also needed but can be deferred to the next update.
— Trappist the monk ( talk) 13:03, 29 April 2017 (UTC)
Done. The changes to Module:Citation/CS1 were not so complex as I imagined so that has been done also.
— Trappist the monk ( talk) 09:44, 30 April 2017 (UTC)
Now that |coauthors=
is unsupported, we should be able to delete
Category:CS1 errors: coauthors without author, I believe. Do we need code changes to the module, or can we just delete the category? –
Jonesey95 (
talk) 13:38, 30 April 2017 (UTC)
The template commons:Template:Cite_journal on Wikimedia Commons does not have implemented parameters first1= |last1= |first2= |last2= etc. commons:Template talk:Cite journal#Parameters. Could you improve it, please? This is crucial for proper referencing of images. Thanks. -- Snek01 ( talk) 18:51, 1 May 2017 (UTC)
There is a metadata bug. Somehow, some of the multiple bytes of unicode characters outside of the ascii character set are not all included in the metadata:
{{cite book |title=Я}}
produces this metadata for the title:
&rft.btitle=%D0%AF
– correctand:
{{cite book |title=ש}}
&rft.btitle=%D7%A9
– correctbut:
{{cite book |title=魂}}
&rft.btitle=%E9%82
– should be: %E9%AD%82
and:
{{cite book |title=–}}
&rft.btitle=%93
– should be: %E2%80%93
From these simple examples, it would appear that something is buggering up three-byte unicode percent encoding. This problem was apparently noticed just after the 29–30 April 2017 update to the live module suite. I am at a loss to explain this problem as a result of the changes that were incorporated in the update. So, I have reverted the sandboxen to the last live version before the update. Let me repeat that:
After reverting to the last live version, the simple tests above produce the same results.
The modules use the function mw.uri.encode()
to percent-encode metadata and also to encode identifiers like |doi=
. If I make up a doi with a character that doesn't work in the metadata, the doi link is encoded correctly:
{{cite book/new |title=Title |doi=10.1234/.魂}}
//dx.doi.org/10.1234%2F.%E9%AD%82
From all of this, I know that the problem has been with us for some time and that the problem appears to be confined to the metadata. Now it is just a matter of locating it.
— Trappist the monk ( talk) 15:19, 2 May 2017 (UTC)
value = value:gsub ('[\226\128\141\226\128\139\194\173]', '')
value = mw.ustring.gsub (value, '[\226\128\141\226\128\139\194\173]', '');
\226\128\141
for zero-width joiner, etc.value
is an en dash, its byte values are \226\128\93
. In the original version, value:gsub()
finds both the \226
and the \128
bytes and removes them leaving the \147 which is later percent encoded to %93. Similarly, 魂 has byte values of \233\173\130
, value:gsub() finds and removes the \173
leaving behind \233\130
which percent encodes to %E9%82
.{{cite book |title=魂}}
'"`UNIQ--templatestyles-00000027-QINU`"'<cite class="citation book cs1">''魂''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=%E9%AD%82&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+33" class="Z3988"></span>
value = value:gsub ('\226\128\138', ' ');
value = value:gsub ('[\009\010\013]', ' ');
value
must match exactly. In the second, like regex, the pattern is a set of three individual bytes so will match with any of the three single-byte characters horizontal tab, line feed, or carriage return.Re: "boxen". Yes, a hacker in-joke, but it has appeared in a headline in a reliable source at least once. It appears in article space with an explanation in a few places, and there's Pizza boxen (a redirect); I agree with David Eppstein that it should not be used casually in article space. – Jonesey95 ( talk) 20:22, 2 May 2017 (UTC)
When User:SpikeToronto recently made this edit and many similar ones, trying to improve the table format for iPads, it actually broke the format for an ordinary Chrome browser on a Windows laptop. For example, unless the browser window is extremely wide, the right side of the table in Template:Cite book/doc#TemplateData gets truncated, cutting off words and the column-sort arrows, with no horizontal scrollbar to reach the truncated content. Is there a way to make these tables work properly on both types of devices? — Patrug ( talk) 07:22, 3 May 2017 (UTC)
{{
TemplateData}}
which, I gather has the job of rendering the TemplateData table.{{
TemplateData}}
doesn't have the job of rendering the TemplateData table.Can a new maintenance category be created (and coded into
Module:citation/CS1) for when Archived copy
is used as a title in a cite-template? Currently we have 38 000+ articles (
insource:/\|title\=Archived copy/), and I bet that not a single one of them should use that as a title. (
t)
Josve05a (
c) 14:48, 29 April 2017 (UTC)
|work=
Wayback Machine
& |work=Wayback Machine
--(
t)
Josve05a (
c) 15:16, 29 April 2017 (UTC)
|title=Archived copy
.
72.43.99.146 (
talk) 12:44, 4 May 2017 (UTC)Hi, I was wondering why the volume and page numbers were separated so much in
Template:Cite encyclopedia? Right now the volume separated from the pages by the edition, publishing location, and publishing house. Should I be using |at=
instead so that the volume of the encyclopedia immediately precedes the page numbers, as in Chicago or APA?
Because right now I think it's unclear to have the volume so far from the pages as in:
{{
cite encyclopedia}}
: |last1=
has generic name (
help)I would expect it to be something like:
{{
cite encyclopedia}}
: |last1=
has generic name (
help)Thanks. Umimmak ( talk) 15:39, 8 May 2017 (UTC)
A primary goal when we integrated all of the old wikitext cs1|2 templates into the new Lua
Module:Citation/CS1, was to make the new look like the old. Apparently we were successful with the |volume=
/ |page(s)=
aspect of that integration for {{
cite encyclopedia}}
:
Wikitext | {{cite encyclopedia
|
---|---|
Live | Author, A. (2017). "Entry". In Editor, E. (ed.). Title of Encyclopedia. Vol. 3 (2nd ed.). City: Publishing House. pp. 100–102. {{
cite encyclopedia}} : |last1= has generic name (
help)
|
Sandbox | Author, A. (2017). "Entry". In Editor, E. (ed.). Title of Encyclopedia. Vol. 3 (2nd ed.). City: Publishing House. pp. 100–102. {{
cite encyclopedia}} : |last1= has generic name (
help)
|
The rendering of {{cite encyclopedia}}
looks much like the rendering of {{
cite book}}
given similar parameters:
{{cite book |last1=Author|first1=A.|date=2017|chapter=Chapter |title=Title of Book |edition=2nd|editor-last=Editor|editor-first=E.|volume=3|pages=100–102|publisher=Publishing House|location=City}}
If you are concerned, you might research the issue in the archives of this talk page and the archives of the {{cite encyclopedia}}
talk page. There may be something there that will explain why the original authors of {{cite encyclopedia}}
did what they did. Or not.
Contructs like this:
|at=Vol. 3, {{pp.|100|102}}
are discouraged because it introduces volume information into an in-source element of the metadata.
— Trappist the monk ( talk) 16:15, 8 May 2017 (UTC)
|page=
, |pages=
, and |at=
are
in-source location parameters; all map to a key called &rft.pages
; volume information does not belong there. There is a cs1|2 parameter specially intended to hold volume information: |volume=
which feeds &rft.volume
.|page=
.
Umimmak (
talk) 20:35, 8 May 2017 (UTC)I recently had a FAR where a user pointed out I was using a Japanese book and that I needed to provide both the original Japanese prose of the book's information and the English translation. Would it be "quote=Japanese and trans_quote=English"? Regards, Tintor2 ( talk) 00:08, 5 May 2017 (UTC)
|quote=Japanese quote</q> <q>[English quote]
– the </q> <q>
are used here because the quotation marks around |quote=
are formed that way
Japanese quote.
[English quote.]
... ています</q> <q>Hoshino: Guess ...
</q>
following the original language quote closes the opening <q>
provided by the template. Similarly, the <q>
preceding the English translation matches the closing </q> provided by the template. And thus, all is in balance.|trans-quote=
parameter (some while ago). This would be following the basic principle to keep different types of contents in different parameters.|quote=
and |trans-quote=
we'd be free to change the output format whenever this might become necessary in the future, even depending on settings or target devices. We might even suppress the translation if it would not be desired in a certain context. Example:<ref>{{citation|...}}. "ています" is translated [by whom?] as "Hoshino: ...".</ref>
|trans-quote=
parameter which explains why it did not work.I agree putting a quotation inside a citation template is probably a bad idea. One reason it's a bad idea is quotations might need all kinds of special stuff to reproduce what's in the source, like a table for instance. Such complex markup would be very likely to break the citation template.
However, I disagree that a quote from a source should either be placed in the running text of the article, or omitted. Most citations in Wikipedia are in the form of an endnote. Endnotes are for details that distract from the point being made in the running text of the article. Such detailed digressions might very well need quotations from the source. Thus, there's nothing wrong with including quotes from the source in a footnote. Jc3s5h ( talk) 12:54, 6 May 2017 (UTC)
a source should either be placed in the running text of the article, or omitted; I made no mention of
running text. Do not put words into my mouth that I have not spoken. By
put the quote in the article and cite it, I simply meant that the quotation, if required, should be placed somewhere other than in the citation itself.
third opinion. Clarify?
|quote=
at
WT:Verifiability#How does one transparently cite more than one part of an e-book in a single citation?: to provide a short piece of text that can be searched for to locate the section referenced in media such as certain e-books that do not have pagination or other in-source indices. But even that can be handled outside of the template. ~
J. Johnson (JJ) (
talk) 20:27, 8 May 2017 (UTC)Please see/join this discussion about a bot conversion of some existing reference lists making use of unordered lists (*) instead of definition lists (:). — TheDJ ( talk • contribs) 14:07, 12 May 2017 (UTC)
I can't see a field for a subtitle. Is this a deliberate policy decision or an omission? -- Pfold ( talk) 11:53, 6 May 2017 (UTC)
|subtitle=
parameter. Most often, if a subtitle is required, it is included in |title=
set off from the main title with a colon:
|title=Main Title: Subtitle
|subtitle=
is a policy decision or an omission. You might troll through the archives of this page, the talk page archives of the individual templates before they were merged into this page, and the talk page archives for {{
citation}}
.|sub-title=
(or similar) parameter. I would welcome its introduction in the English Wikipedia as well. --
Matthiaspaul (
talk) 00:14, 14 May 2017 (UTC)|title-separator=
parameter could be used to specify it, otherwise the template would default to some internal default like " - ".|title-link=
and |url=
. In this case, our templates throw an error message, as there is only one string to attach the link to. |sub-title=
could help remedy this situation, as the second link could be attached to the sub-title then - not a perfect solution, but still better than having to append raw links after the citation.{{
cite journal}}
: Check |issn=
value (
help); Invalid |ref=harv
(
help)That ISSN resolves to the correct title, yet the template flags it as problematic. What gives? Headbomb { t · c · p · b} 12:04, 15 May 2017 (UTC)
{{issn|1225-8989}}
The visual design RFC for the access locks concluded with an essentially 50-50 split community on the colour of the "free with conditions" lock (yellow vs blue). This RFC is to investigate support for a third option (grey). Headbomb { t · c · p · b} 14:55, 22 April 2017 (UTC)
The paste options were 1&2
People who supported this cited the intuitiveness of the traffic light colour scheme, people who opposed it mostly cited the yellow not being very yellow, and the colourblind-friendlier blue.
People who supported this cited the yellow not being very yellow in the previous scheme, and the colourblind-friendlier blue. People who opposed this cited the lack of a recognizable colour scheme of any sort. It also tends to get lost in a sea of blue. This had marginally more support (1 more !vote out of 22 or so).
However, late in the RFC, an alternate colour scheme was proposed as an alternative and garnered some support, but it was too late in the RFC to be introduced an option. Let's consider it now.
This has neither drawback of schemes 1 & 2. Green/Grey/Red is an intuitive colour scheme, is just as colourblind friendly as Green/Blue/Red, and doesn't get as lost in the sea of blue as the blue one does. I'd have included arguments against grey, but I know of none.
Basically, how this would look is something like
Support #3 as proposer. Headbomb { t · c · p · b} 14:55, 22 April 2017 (UTC)
Oppose all. See below. – Finnusertop ( talk ⋅ contribs) 01:46, 6 May 2017 (UTC)
I do not know whether this is the proper procedure, considering that the referenced RFC was submitted at a much better attended forum. At best, imo whatever discussion results here, should be used to stage a proper RFC at the proper forum. Especially since the original RFC seems inconclusive on the related issues. 65.88.88.126 ( talk) 20:56, 22 April 2017 (UTC)
Hey All; at the WMF we have been working with OCLC to make ISBN generated citations available, through using their ISBN database. We have deployed the feature on all language Wikipedias: you can learn more about it on the Wikimedia blog. Astinson (WMF) ( talk) 19:29, 11 May 2017 (UTC)
|df=
for the first problem, if you don't simply want to use a script such as the one that
Ohconfucius provides. The WMF developer team is unwilling to let us get the dates in the format we wish. As for the second problem, using ISO dates allows for ambiguity in the form of 1993-00-00 to indicate that the year is known but not the month nor day, as well as 1993-01-00 to indicate that year and month are known, but not the day--I do not know why they use 01 instead. (It impacts Wikidata too, but I haven't thought to comment there yet.) --
Izno (
talk) 20:32, 11 May 2017 (UTC)
|location=Ljubljana
; the Gallery Citation left out both |location=
and |publisher=
.{{cite book|last1=Maps|first1=Peekaboo|title=Berkeley, Oakland : Albany, Emeryville, Alameda, Kensington|date=2009|publisher=Peek A Boo Maps|location=[Berkeley?]|isbn=9783161484100|edition=1st ed.}}
{{
cite book}}
: |edition=
has extra text (
help)|citoid=
) which when equal to oclc
, creates a green maintenance category message with some text of the sort: "CS1 maintenance: Citations imported from
OCLC", if we believe that OCLC is so poor a quality of reference and that no-one will go back to fiddle with parameters. For reference, I know I use Citoid now for other websites and its hit-or-miss-enough in general such that I always check the imported citation, so I'm not sure if such a parameter is even necessary, since I would guess most others who use the service have a similar workflow. --
Izno (
talk) 22:06, 12 May 2017 (UTC)On a related issue, Mediawiki's refusal to use any date format other than YYYY-MM-DD in their cites (because they don't want to go through the hassle of full internationalization): in response to this, we could always be passive-aggressive about it and modify the cite templates to put up big red edit-time warnings when they see dates in this format in the date field (not the accessdate where they are ok): "Warning: Numeric date format detected. Please convert all dates to the prevailing style of the article." Because unless the users of the citoid template see it as not properly working, they won't notice the work it causes the rest of us and won't be motivated to do anything about the problem. — David Eppstein ( talk) 16:30, 12 May 2017 (UTC)
For some reason I was under the impression that the "cite journal" would accept a "license" parameter where one could indicate, e.g., "CC BY". I do not see it. Is there any (other?) way to indicate this? — fnielsen ( talk) 12:39, 20 May 2017 (UTC)
Related to the discussions at Help_talk:Citation_Style_1#ISBNs_in_mw:Citoid and T132308.
Because WP:DATE does not allow year initial numeric dates in the form YYYY-MM but does allow YYYY–YY (with an en dash), and because cs1|2 emits an error when the MM or YY portion of those dates is in the range 00–12 inclusive, and because citoid needs to be able to transfer dates to all of the different language wikis, it has been suggested that citoid use the Extended Date/Time Format (EDTF). A draft of the standard is here.
For us, the immediate issue is the YYYY-xx date form. EDTF provides an alternate way to encode that kind of date. Similar in form to YYYY-MM-DD, EDTF allows for portions of the date string to be declared as 'unspecified'. When citoid needs to send en.wiki a month and year date, it can take the form |date=YYYY-MM-uu
. That date format would surely violate WP:DATE so needs to be transformed into a more appropriate form. I have hacked the module sandbox to accept and transform dates that are provided in this style:
{{cite book/new |title=Title |date=2000-06-uu}}
Similar to the transformations preformed for |df=
and for auto-changing hypens to dashes, if there are any date errors in the citation, even in unrelated parameters, the module will not do any transformations. Here, using the same format for |access-date=
, causes an error because |access-date=
requires a day:
{{cite web/new |url=//example.com |title=Title |date=2000-06-uu |access-date=2017-05-uu}}
— Trappist the monk ( talk) 16:45, 18 May 2017 (UTC)
In preparation for the WikiCite event, currently taking place in Vienna, I have built a demonstrator template, {{ Cite Q}}. Much work remains to be done, to deal with more complex use cases, and to resolve the issues listed there. Hopefully that will be addressed during the WikiCite hackathon, on Thursday (CET time, GMT +2). Your comments and remote participation will be welcome. Please use the template's talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:09, 23 May 2017 (UTC)
This
edit request to
Template:Cite web has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
I would like to make an edit request adding a new lastnamefirst parameter. It changes the name order in citations, defaulting to yes. Change it to no for Icelandic names. Numberguy6 ( talk) 15:54, 23 May 2017 (UTC)
{{
edit protected}}
template. This may be a valuable discussion to have but it certainly does not have a consensus at this time. What reason do you propose to make this change?
Izno (
talk) 16:13, 23 May 2017 (UTC)Is there a way in this family of templates to be able indicate the licensing of the cited material? I am particularly interested in being able to mark a citation as being Creative Commons licensed so that the reader can see if it can be re-used. As Wikipedians, we are generally in favour of information being open and reusable. While I can see that we support expressing whether a source is free/subscription/etc (which affects "open"), I cannot see a similar way of expressing the source's potential for re-use. As a writer of Wikipedia, I would love to be alerted to CC-licensed materials (particularly the ones that enable re-use on Wikipedia itself). I write a great deal about Queensland, Australia, and there are a lot of government resources that people don't realise are CC-BY licensed and I'd like to alert readers (and other writers) to this when citing them. Is there a way to do it? Or do I have to do it after the cite template and before the closing ref tag as I did at State Strategic Touring Route. Thanks Kerry ( talk) 08:18, 27 May 2017 (UTC)