Module talk:Citation/CS1/Archive 8

Archive 5

Archive 6

Archive 7

Archive 8

Archive 9

Archive 10

→

Archive 12

Deprecated day and month

All of the CS1 templates contain a notice that lists these deprecated parameters:

|access-date=, |accessed=, |accessdaymonth=, |accessday=, |accessmonthday=, |accessmonth=, |accessyear=, |day=, |dateformat=, and |doilabel=

Of these, |access-date= was recognized as a current parameter. I have moved it from the configuration sandbox argument map to the suggestions list. All of the others are recognized as unknown parameters except |day=.

I'm not sure what should be done with it. It's deprecated but is used in the code along with |month= and |year= to assemble a date. CS1 should be consistent. If |day= is deprecated, shouldn't |month= also be deprecated; both in favor of |date=?

—Trappist the monk (talk) 15:28, 16 April 2013 (UTC)

Previous discussion: Help talk:Citation Style 1/Archive 1#day. I think we could do away with |year= as well. When the templates were initially developed, #time function would give spurious output if you tried to process a year only as a date if it looked like a time— that was fixed in MediaWiki some time ago. --  Gadget850 (Ed) ^talk 15:42, 16 April 2013 (UTC)

• Parameter "month=" is for journals and "day=" completes a date: Both of those parameters have logical uses, and rejecting "day=" would just frustrate the year/month/day idiom for dates. Also, remember how "year=1995b" will override the year in "date=" to set "1995b" into anchor text for the Harvard referencing. -Wikid77 (talk) 15:46, 16 April 2013 (UTC)
• Anything that goes in the date field is displayed as is. The key is in how the year is extracted to use in the anchor. All of these correctly extract the year:
  • Drucker (2013). Book. {{cite book}}: Invalid |ref=harv (help)
  • Drucker (May 2013). Book. {{cite book}}: Invalid |ref=harv (help)
  • Drucker (2 May 2013). Book. {{cite book}}: Invalid |ref=harv (help)
  • Drucker (May 2, 2013). Book. {{cite book}}: Invalid |ref=harv (help)
  • Drucker (2013 2013). Book. {{cite book}}: Check date values in: |date= (help); Invalid |ref=harv (help)

but not these:

• Drucker (23 2013). Book. {{cite book}}: Check date values in: |date= (help); Invalid |ref=harv (help)
• Drucker (Flubtember 2013). Book. {{cite book}}: Check date values in: |date= (help); Invalid |ref=harv (help)

--  Gadget850 (Ed) ^talk 17:00, 16 April 2013 (UTC)

The above list of Drucker cites was, I think, posted by Editor Gadget850.

I looked at {{cite journal}}. There, |month= is an available parameter but it looks like it is always combined with |year= to be used as |date=. Without |year= it is ignored. I am in favor of deprecating |month= and |year=. As an adjunct, I think that CS1 should report an error if |date= is malformed.

—Trappist the monk (talk) 16:33, 16 April 2013 (UTC)

Yes, that was me. And yes, we should do an error check on the date. We should do this one later if we intend to deprecate day, month and year. --  Gadget850 (Ed) ^talk 17:00, 16 April 2013 (UTC)

Year and date are not actually handled identically. If both are given, date= is displayed, but year= is mapped in to the CITEREF. Hence:

{{cite journal |last=Drucker |title=My article|journal=My Journal |date=May 12, 2013 | year=2013c | ref=harv}}

Drucker (May 12, 2013). "My article". My Journal. {{cite journal}}: Invalid |ref=harv (help)CS1 maint: date and year (link)

has id="CITEREFDrucker2013c"

This is used by {{sfn}} / {{harv}} to reference works where the same author had more than one publication in a calendar year, thus creating links for Smith 2001a, Smith 2001b, etc. I think it would be hard to remove year without creating problems for usages like this. Dragons flight (talk) 18:10, 16 April 2013 (UTC)

Hmm, problematic, that. |date= and |year= are synonymous in the same way that |author= and |last= are synonymous. As such, both |date= and |year= in the same citation should cause a redundant parameter error. And you can't just set |date=16 April 2013c; it doesn't work, you don't get id="CITEREFDrucker2013c". And besides, it looks ugly, just as citations without |date= look ugly now when editors must set |year=2013c in order to appease the short footnote god (is the god short, or is the footnote short?)

Perhaps |year= still gets deprecated in favor of |date=. Create a new synonym for |year=: |refyear= which only applies when |ref=harv. CITEref is assembled from |date= except when |refyear= is present in which case CITEref is assembled from |refyear=. Error conditions are:

|date= and |year= without |ref=harv → Redundant parameter error

|refyear= without |ref=harv → |refyear= requires |ref=harv

|year= without |date= → |year= deprecated, suggest |date=

A robot could be trained to sift through the articles to upgrade citations with |year= to either |date= or |refyear=.

Eschew inconsistency.

—Trappist the monk (talk) 19:08, 16 April 2013 (UTC)

It would be simpler to keep date and year. Editors who use these styles are accustomed to using date for the visual date and year for the anchor year. Regardless, date now accepts day-month-year, month-year and year with no issues, so day and month can be deprecated. I would not yank support yet. --  Gadget850 (Ed) ^talk 19:54, 16 April 2013 (UTC)

That sounds like the we've-always-done-it-this-way-and-if-it-was-good-enough-for-my-grandfather-it's-good-enough-for-me argument. We are at a place where we can and should make changes to consolidate CS1 into a suite of citation tools that will serve well and long – until the next disruptive technology arises.

Yes it would be simpler, but what I've proposed doesn't, to my novice eye (that was a disclaimer), seem much different from what we've already done. We already deal with redundant parameters; we already handle suggested parameter names; with careful inspection, replacing |year= with |refyear= should be relatively painless.

Will there be pushback from the editing community? Could be, but if that occurs, I think that with careful explanation, the reasons will be accepted. Despite bleeding red all over thousands of articles, CS1 and those of you who are creating it, have not earned the undying enmity that might have been expected.

—Trappist the monk (talk) 22:31, 16 April 2013 (UTC)

I was taught the three Es: engineering, education, enforcement. The problem on Wikipedia is that there is no centralized way to do the education part. Once editors start doing something, they tend to keep doing it that way until something slaps them in the face and they have to change their methods (and it is pretty much that way in life). We can do a lot of the enforcement through engineering: error checking and messages is a major method. But, we don't have to change thing just to change them. The current methods work, but can use some improvement. I just don't see the need to change 'year'. If we keep 'date' as the main date and 'year' as either a year or a year descriptor, then we keep backwards compatibility and it is one more thing we do not have to enforce. Frankly, getting rid of 'day' and 'month' would be the bigger issues. We can start by deprecating them in documentation, and I will start that task. --  Gadget850 (Ed) ^talk 17:51, 18 April 2013 (UTC)

Here's another of aphorism to go with your three Es: The quick is now, the dirty is forever.

Ok, how about this? Since we already have to extract a year from |date= when |year= is omitted, allow extra text in |date= that can serve as a year disambiguator. Put some restrictions on it: the disambiguator shall be no more than two characters, the first of which must be a letter; it shall directly follow the year portion of the date without intervening spaces so |date=2013cb-04-18 or |date=18 April 2013a6 or |date=April 18, 2013r. The year disambiguator is never displayed but is used with the year value extracted from |date= to create CITEREF.

Because |year= is synonymous with |date=, CS1 reports a redundant parameter error whenever both are used in the same citation. So that legacy citations continue to work, when |year= and |date= are present in the same citation with |ref=, CS1 will use |year= to create CITEREF. This ensures that short-footnote links aren't broken when |year= has a disambiguator. |year= is deprecated but allowed to remain usable – for the time being. Documentation reflects this deprecation.

This still permits us to deprecate |day= and |month=.

—Trappist the monk (talk) 00:20, 19 April 2013 (UTC)

'date' and 'year' are not aliases, they function separately, as expected:

Markup	Renders as
{{cite book |last=Drucker |title=Book |date=May 2, 2013 |year=2013c |ref=harv}}	Drucker (May 2, 2013). Book. {{cite book}}: Invalid |ref=harv (help)CS1 maint: date and year (link)

If 'date' and 'year' are both defined, then 'date' is shown and the anchor is formed from 'year'. In this example the visual date is May 2, 2013 and the anchor is CITEREFDrucker2013c. --  Gadget850 (Ed) ^talk 00:13, 20 April 2013 (UTC)

I must be losing my ability to communicate.

You're right, because of the need for disambiguation, |date= and |year= aren't strictly symmetrical synonyms. We use |year= with |date= to disambiguate citations. When there is no need to disambiguate the citation, there is no need for both so, as is the case with |author= and |last=, CS1 should report a redundant parameter error. Are there any other reasons to use |year= with |date=?

The use of |year= as a citation disambiguator was a necessary response to limitations imposed by the MediaWiki #time function. This is legacy that need not be duplicated or preserved. #time returns an error or strips-off text that isn't part of the date parameter:

{{#time:Y|May 21, 2013c }} → 2013

{{#time:Y|21 May 2013c }} → 2013

{{#time:Y|2013c-05-21 }} →

I speculate that this is the reason that |year= was preserved after it became possible to extract the year from |date=. With Lua, that impediment has been lifted. We can decide to allow disambiguation in |date= and then deprecate all three of |year=, |month=, |day=.

As an aside, how were citations disambiguated before the CS1 templates started using #time? Were they? Extraction of year from |date= was added to {{citation}} with this edit.

—Trappist the monk (talk) 14:48, 20 April 2013 (UTC)

Up until about a year ago, running a year only through #time:Y would sometimes result in a time of day, not the year, resulting in a time error and generating no year anchor. Thus the need for the separate 'year' parameter.

'year' is used as the year and as an anchor disambiguator. If we want to migrate to 'refyear', then we have to look for a year with an alpha suffix and move that to 'refyear', otherwise, move it to 'date'.

'day' and 'month' can safely be deprecated.

Is there any objection to changing the documentation now to deprecate 'day' and 'month' and to deprecate 'year' except as a disambiguator? This should be noted at Help talk:Citation Style 1. --  Gadget850 ^talk 12:58, 6 May 2013 (UTC)

But: 'date' does not generate the year anchor if a season is included:

• Drucker (Fall 2013). Book. {{cite book}}: Invalid |ref=harv (help)

But it does work if the season is used in 'month':

• Drucker (2013). Book. {{cite book}}: Invalid |ref=harv (help); Unknown parameter |month= ignored (help)

--  Gadget850 ^talk 13:01, 6 May 2013 (UTC)

The |day= parameter has been tracked as deprecated for a long time; and as far as I can tell, it has never been mentioned in Template:Cite book/doc. However, |month= is not deprecated and sees wide use. The reason that the anchor is not correctly generated for |date=Fall 2013 is because the {{#time:}} parser function expects a valid date. --Redrose64 (talk) 13:41, 6 May 2013 (UTC)

No objection to deprecating |day= and |month=. If we do, we should consider creating a deprecated parameters list and flagging those parameters where they occur so that these citations can be fixed.

Deprecate |year= and create new parameter |refyear= as I've described earlier in this thread. I would add one further argument, the meaning of |refyear= is more-or-less unambiguous. Ambiguity is a bad thing.

WP:SEASON seems to frown on the use of seasons for dates. And, if used in a citation, doesn't season actually belong in |issue= or |number= (presuming that and actual numeric issue identifier doesn't already exist – and which should be preferred)?

—Trappist the monk (talk) 14:10, 6 May 2013 (UTC)

I know this has come up before, and I have seen a season used in 'month'. This isn't a reason to not deprecate 'month'. But it does bring up the related issue that an invalid date causes the anchor to fail silently. I'm going to kick that one to the feature request. And even though 'day' has been deprecated for a long time, it is still parsed. --  Gadget850 ^talk 15:39, 6 May 2013 (UTC)

Looks to me like the value from |date=Fall 2013 is tested to see if it is an integer value between 0 and 2100. If not, something called lang.formatDate evaluates it. If Fall 2013 is not an acceptable date, then the test returns an empty string. This seems somewhat similar to the #time: issue.

—Trappist the monk (talk) 03:33, 7 May 2013 (UTC)

@Trappist: |year= is us\ed far too often to deprecate. As for WP:SEASON: If a publication dates itself by seasons, then that should be how we date it. We should not be putting parts of the date into a volume or issue number unless they really are parts of the volume or issue numbers. —David Eppstein (talk) 15:43, 6 May 2013 (UTC)

[Now why did they go and move the section edit button?] I specifically said deprecated precisely because year has been used a lot. Deprecated is vastly different from deleted. If a periodical solely identifies issues by season and doesn't have equivalent issue-numbers, then there is an issue (pardon the pun). Where there are issue-numbers in conjunction with season, the issue-number should be used in the citation because of WP:SEASON and WP:DATEFORMAT.

—Trappist the monk (talk) 21:27, 6 May 2013 (UTC)

I know the difference between deprecation and deletion and I stand by my statement that year is used far too often even to deprecate. It's useful to have years that don't parse as dates (e.g. for years like 1999a when there are two 1999 pubs by the same author and they need different harv reference links, or for years like 2000–2003, or whatever). And I don't want to encourage editors to change the many articles that use year parameters to something else, for no purpose. The templates are now fast. Having both year and date is not a problem that needs fixing. —David Eppstein (talk) 04:01, 7 May 2013 (UTC)

One of the issues discussed in this thread has been addressed. The 2013-09-02 version of Module:Citation/CS1/sandbox supports seasons in |date=. See Anchors from dates with seasons.

—Trappist the monk (talk) 11:15, 13 September 2013 (UTC)

Tracking use of language icons in language field

Would it be possible to have a method for tracking the usage of language icons in the language field? In particular, to help with correcting like this. Could probably be found by checking if the value passed matches >span class="languageicon". Thanks! Plastikspork _―Œ^(talk) 17:37, 14 September 2013 (UTC)

I don't have an absolutely, positively, for sure answer but I suspect it's possible. In fact, I've just been wondering if allowing templates like {{es icon}} to be specified as a value: |language={{es icon}} might not be a step toward better language support in the CS1 templates. The language icon templates like {{es icon}} call {{Language icon}} which adds the styling and categorization.

The translation of this simple citation: {{cite web |url=http://www.example.com |title=Example |language={{es icon}} }} is:

<span class="citation web">[http://www.example.com "Example"] (in <span class="languageicon" style="font-size:0.95em; font-weight:bold; color:#555;">(Spanish)</span>[[Category:Articles with Spanish-language external links]]).</span>

We might strip the styling and leave the language and its category and, voilà, the citation is categorized – there's a feature request that runs along those lines. Of course that "solution" is a quick and dirty solution and as we all know, the quick is now, the dirty is forever so I'm hesitant to do that.

Setting that aside, how would you want this to work? Detect and add a tracking category? Detect and strip everything but the language and then add tracking category? Show an error message? Something else I haven't thought of?

—Trappist the monk (talk) 20:13, 14 September 2013 (UTC)

Toward better language support

Somewhat related to #Tracking use of language icons in language field:

I have added to the sandbox, code that will allow editors to specify |language= using the two-character iso639-1 language codes. This, I think is the first step toward adding better language support to CS1. Still to do with this bit is to add categorization à la {{es icon}}, {{de icon}}, {{fr icon}}, etc.

The iso639-1 code is case insensitive:

Cite book comparison

Wikitext	{{cite book|language=FR|sandbox=yes|title=Title}}
Live	Title (in French). {{cite book}}: Unknown parameter |sandbox= ignored (help)
Sandbox	Title (in French). {{cite book}}: Unknown parameter |sandbox= ignored (help)

If the |language= value isn't recognized as an iso639-1 code, CS1 uses the value:

Cite book comparison

Wikitext	{{cite book|language=Squeamish|sandbox=yes|title=Title}}
Live	Title (in Squeamish). {{cite book}}: Unknown parameter |sandbox= ignored (help)CS1 maint: unrecognized language (link)
Sandbox	Title (in Squeamish). {{cite book}}: Unknown parameter |sandbox= ignored (help)CS1 maint: unrecognized language (link)

—Trappist the monk (talk) 15:18, 15 September 2013 (UTC)

Now categorizes citations in mainspace articles when the iso639-1 code is no 'en' (English). This behavior matches that of the {{xx icon}}/{{language icon}} templates. Pages are placed in the appropriate [[Category:Articles with <language>-language external links]].

—Trappist the monk (talk) 17:30, 15 September 2013 (UTC)

|template doc demo=true does not exclude articles from subcategories of Category:Articles with incorrect citation syntax

Template:Cite_book says that "|template doc demo=true" is supposed to exclude templates from Category:Articles with incorrect citation syntax, but now that articles are being placed into subcategories, that appears not to work.

For example, Template:Cite rowlett/doc contains that parameter but the template exists in Category:Pages with citations having wikilinks embedded in URL titles, a subcategory of Category:Articles with incorrect citation syntax. According to the documentation, the intent of the parameter is that the template should not be placed in that error category. Did I explain this well enough for someone to make the CS1 module conform to the documentation, if it should indeed be fixed? – Jonesey95 (talk) 13:50, 13 September 2013 (UTC)

I don't think that this is the fault of Module:Citation/CS1. The parameter |template doc demo=true is not being passed to the underlying {{cite web}} by {{cite rowlett}}. Because {{cite web}} isn't getting |template doc demo=true it is correctly categorizing the error that it's seeing.

—Trappist the monk (talk) 14:10, 13 September 2013 (UTC)

So how can this problem be fixed? – Jonesey95 (talk) 23:24, 15 September 2013 (UTC)

You just need to pass the parameter through, like this. --Redrose64 (talk) 23:48, 15 September 2013 (UTC)

Nice. That seems to have done it. The /doc page needed a null edit, after which the article is not in the error category anymore. Thanks to both of you. – Jonesey95 (talk) 14:54, 16 September 2013 (UTC)

Hyphens

There's a function "hyphentodash" in this module that is, I guess, intended to "fix" user input errors where a Wikipedia editor types a page range like 1-25, not knowing that it should be properly formatted as 1–25. Often that's the right thing to do, but not always. I encountered a situation today where the page numbers ranged from 3-1 to 3-25 (that is, pages 1 to 25 of chapter 3 of.... For this type of page number, a hyphen should be used to separate the chapter part of the number from the page part of the number. Trying to format this as part of a {{citation}}, I had a very difficult time getting the hyphens to stay hyphens. I eventually ended up hiding them from the conversion by encoding them as - — is there a better way? Maybe the automagic conversion should recognize that something like |pages=3-1 – 3-25 doesn't look enough like the expected page range format for conversion to be safe? —David Eppstein (talk) 04:57, 19 September 2013 (UTC)

• Perhaps note how "at=" or "page=" allows hyphens: It will be difficult to rework the hyphentodash() function to make "clever" become "cleverer" enough to realize "3-1" is not the start of a page range. Any URL in the page number (or volume) will stop hyphen-to-dash filtering. The use of &#45 is one option, but also remember parameter "at=" allows unfiltered page numbers, such as "at=pp. 3-1 to 3-25" and I recommend updating the doc-text to warn users how hyphens will be switched to dashes in "pages=" (not in "page=") but use "at=pp.__" to set the page number to an unfiltered range. Otherwise, this would be a complex problem to reach consensus for more clever detection of valid hyphens. Does a warning in the doc-text to use "at=pp.___" seem acceptable? -Wikid77 11:18, 19 September 2013 (UTC)

Documentation updated to recommend |at= in these cases.

—Trappist the monk (talk) 13:26, 19 September 2013 (UTC)

Accept language codes as well as language names

The {{#language}} parser allows us to support both language codes and language names without any conflict. In a template, the coding for that would be {{#ifeq: {{#language:{{{language|}}}}} | {{{language|}}} | {{{language|}}} | {{#language:{{{language|}}}}} }}, but I have no idea how to do that in Lua. (As an aside, I'm aware that that syntax is rather ugly, and have filed a bug to make it somewhat less so.) Still, I think this would be useful, and I'd very much appreciate if someone who knows their way around Lua could help out here. — PinkAmpers&^{(Je vous invite à me parler)} 21:39, 19 September 2013 (UTC)

I'm not sure if you're asking something or offering something. I'm an idiot sometimes so it might just be me. There is a Lua module Module:ISO 639 name that might be of interest to you.

—Trappist the monk (talk) 04:08, 20 September 2013 (UTC)