Module talk:Citation/CS1/Feature requests
This page is used to make requests for new features for the Lua based CS1 templates. Please understand that the priority is to update and debug the older templates before implementing new features.
Asian titles
Main work titles are formatted in italics. This is not appropriate for Asian scripts such as kanji, hangul and the like. Asian titles may also be underlined or placed in brackets 『』 or 《》.
See {{Asiantitle}} for current support. --— Gadget850 (Ed) talk 14:36, 29 March 2013 (UTC)
- And such styling should be done with CSS per #Presentation and content. -- Gadget850 (Ed) talk 14:42, 1 April 2013 (UTC)
Language
Titles should be wrapped with markup indicating the language. --— Gadget850 (Ed) talk 14:37, 29 March 2013 (UTC)
- How would this actually work? You have some template examples in mind maybe? Dragons flight (talk) 18:57, 8 April 2013 (UTC)
Presentation and content
The CSS styling for <cite> has been defaulted, so it now formats the contents as italics, while adding the semantic meaning of a title. Thus the current use of italics to format the main work title can be replaced by <cite>...</cite>.
| Markup | Renders as |
|---|---|
<cite>Title</cite> |
Title |
--— Gadget850 (Ed) talk 01:04, 28 March 2013 (UTC)
- What a contorted way to confuse everyone everywhere: Everyone knows that most titles are to be placed in quotation marks, as article titles which far outnumber others. Historically, book titles were underlined, because in handwritten documents, the cursive script is somewhat italicized, and the underlined text was obviously a book/film title. In the search for distinctive vocabulary, we have been calling each "{{cite_web|...}}" with the term "cite" as the markup used to display a citation. Then we introduce a cite-tag "<cite>" which forces the rare use of italic text, to all text, within
<cite>...</cite>. Naturally, most normal humans will begin to associate the term "cite text" with the styling as italic text. What a contorted way to confuse everyone, everywhere. I have a strong hunch the cite-tag will not be very much help in the long run. -Wikid77 (talk) 04:12, 28 March 2013 (UTC)
<cite>would be used internally in the template, so I am confused as to how anyone would be confused. It has an HTML semantic value indicating the title of a work.[1] If we want to add the semantics for an included work title which is marked in quotes, then we can easily style the tag. And with almost half a million uses of cite book alone, I would not call the italic title rare. --— Gadget850 (Ed) talk 09:30, 28 March 2013 (UTC)- Isn't this the problem the IP was discussing earlier, where we're really using the "title" paremeter for multiple semantic functions? Choess (talk) 18:11, 29 March 2013 (UTC)
- I refactored the original proposal to indicate that by title I meant the main work title. Currently, we have no separation of presentation and content. That is, the format of the main work title is always italics, and the included work is always in quotes. This presentation should be moved to CSS. Wrapping the main work title in
<cite>...</cite>will present the title in italics by default. We can add a class to present the included title in quotes. - Since this would be a new feature, I will be moving this to Module talk:Citation/CS1/Feature requests. --— Gadget850 (Ed) talk 18:53, 29 March 2013 (UTC)
- To expand on separation of presentation and content: currently the templates include both content and presentation, that is the markup used to style the content as italics, in quotes or bold. Hard coding the presentation means that readers cannot style citations as they desire and it limits template portability. Presentation should be done in CSS. Currently the
<cite>tag has a default style of italics and has the semantic meaning of a title. - For an included work title that is presented in quotes, we can create a class with CSS styling. For example the class
includedtitle:
- To expand on separation of presentation and content: currently the templates include both content and presentation, that is the markup used to style the content as italics, in quotes or bold. Hard coding the presentation means that readers cannot style citations as they desire and it limits template portability. Presentation should be done in CSS. Currently the
- I refactored the original proposal to indicate that by title I meant the main work title. Currently, we have no separation of presentation and content. That is, the format of the main work title is always italics, and the included work is always in quotes. This presentation should be moved to CSS. Wrapping the main work title in
- Isn't this the problem the IP was discussing earlier, where we're really using the "title" paremeter for multiple semantic functions? Choess (talk) 18:11, 29 March 2013 (UTC)
.includedtitle:before {font-style: normal; content: '\22';}
.includedtitle {font-style: normal;}
.includedtitle:after {font-style: normal; content: '\22';}
- Then you simply wrap the content in
<cite class="includedtitle">...</cite>causing the font to show as normal and the content wrapped in quotes. - The HTML classes discussion does not include a class for the included work title, so I made up an illustrative class. --— Gadget850 (Ed) talk 14:58, 30 March 2013 (UTC)
- Then you simply wrap the content in
Name suffixes
The COinS implementation guide specifies that, at least for the first author of a work, it should be possible to separate their name into first name(s), last name, and suffix. When the {{cite}} templates were created, they were regarded solely as presentational, and separate parameters for suffixes weren't thought to be worth implementing. Scanning the ends of first1, first2, editor1,...and so forth for "Sr", "Jr", "II", and "III" should probably pick up most of the citations where suffixes should be moved to their own parameters. Choess (talk) 15:26, 30 March 2013 (UTC)
- We should still add parameters for those oddball suffixes. -- Gadget850 (Ed) talk 16:58, 30 March 2013 (UTC)
- Sorry, I combined two thoughts. We'd need new "suffix*" parameters for names in general, which could be used for any suffix. The scanning I mentioned could be for a (temporary?) maintenance category to identify citations that would need to be edited to use the new parameters. Choess (talk) 17:15, 30 March 2013 (UTC)
- See Suffix (name). We have no guidelines for suffixes, but you are discussing generational suffixes. I need to check some style guides to see if we should include academic, professional, religious or honorary suffixes. -- Gadget850 (Ed) talk 17:20, 30 March 2013 (UTC)
- OpenURL (COinS) only provides a field for "name suffixes", not titles or degrees. Choess (talk) 17:32, 30 March 2013 (UTC)
- See Suffix (name). We have no guidelines for suffixes, but you are discussing generational suffixes. I need to check some style guides to see if we should include academic, professional, religious or honorary suffixes. -- Gadget850 (Ed) talk 17:20, 30 March 2013 (UTC)
- Sorry, I combined two thoughts. We'd need new "suffix*" parameters for names in general, which could be used for any suffix. The scanning I mentioned could be for a (temporary?) maintenance category to identify citations that would need to be edited to use the new parameters. Choess (talk) 17:15, 30 March 2013 (UTC)
Translator
Add 'translator' parameters. Should show preceded by "Translated by". -- Gadget850 (Ed) talk 19:51, 1 April 2013 (UTC)
- I would appreciate this feature. Could you code this in the same way as authors and editors (eg: "last1=|first1=" etc.), as some works have multiple translators. Mindmatrix 03:20, 2 April 2013 (UTC)
- Just like 'last' and 'first', there would be an unlimited number. -- Gadget850 (Ed) talk 09:38, 2 April 2013 (UTC)
Internet Archive
Can someone familiar with this module add code to enable Internet Archive links for books etc. For example, the open library code OL16525337M is the book "A concise etymological dictionary of the English language", which also has LCCN 11035890 and Internet Archive code cu31924008779690. Thanks. Mindmatrix 03:20, 2 April 2013 (UTC)
- And Google Books ls_XijT33IUC. What other archive systems are used? -- Gadget850 (Ed) talk 09:42, 2 April 2013 (UTC)
- at WebCite users can archive single webpages. the Internet Archive also crawls for site/page snapshots and these may follow the rate of change of the originals. Google Books is different, as it may act more like an online publisher than an archival service. 70.19.122.39 (talk) 00:25, 3 April 2013 (UTC)
Here is the id_handler example for LCCN from Module:Citation/CS1/Configuration.
parameters = {'LCCN', 'lccn'} How specified in the citation template, i.e. LCCN=
link = 'Library of Congress Control Number' Wikipage to link to at the ID label
label = 'LCCN' Text to use for the ID label
mode = 'external' Indicates an external link (the typical case)
prefix = 'http://lccn.loc.gov/' Start of the url to use with the ID
suffix = '' Anything to include in the url after the ID
COinS = 'rft.lccn' Where to map the data in [[COinS]]
encode = false Whether the ID must be urlencoded
separator = ' ' Separator to use between the ID label and the ID
When given LCCN=123456, this generates output that looks like:
[[Library of Congress Control Number|LCCN]] [http://lccn.loc.gov/123456 123456] = LCCN 123456
If you can figure out how to update the fields for Internet Archive, Google Books, or some other ID scheme, then they would be easy to add. A few ID schemes (including Open Library) don't easily map to this format and have to be specially handled, so that is possible too, but it would take more effort. Dragons flight (talk) 19:13, 8 April 2013 (UTC)
- Internet Archive has various media (text, audio, video), but they all appear to have the same URL pattern (http://www.archive.org/details/identifier). Should we create one entry and disregard type, or create separate entries for each, some of which may have subtypes? (For example, some of the audio files could use a handler for Live Music Archive instead of Internet Archive.) I think one handler is probably the better option. Mindmatrix 15:53, 10 April 2013 (UTC)
- In general, I tend to think that less is more in cases like this unless there is a strong reason to differentiate. However, I don't really know much about the Internet Archive, so I'm not really a good person to judge. Dragons flight (talk) 16:37, 10 April 2013 (UTC)
Error message help pages
Each error message should link to a help page. I will take on the task of creating the help. -- Gadget850 (Ed) talk 12:05, 3 April 2013 (UTC)
Page url
Editors often link to specific pages in an online book by wrapping a |page= or |pages= parameter in an external link. This practice can corrupt COinS data for the citation. This feature request suggests the creation of a new parameter that allows editors to continue linking to individual pages without corrupting COinS data. Linking to individual pages is supported at the WP:PAGELINKS guideline, which see.
|pageurl=: URL of an online book's page or pages where the cited text can be found. While not required, if provided, |url= must link to the same source as |pageurl=.
- Examples:
- Single-page link –
|page=18|pageurl=http://books.google.com/books?id=kvpby7HtAe0C&pg=PA18- renders as: p. 18.
- Single-page link –
- Page-range link (to the first page in the range) –
|pages=18–24|pageurl=http://books.google.com/books?id=kvpby7HtAe0C&pg=PA18- renders as: pp. 18–24.
- Page-range link (to the first page in the range) –
- –or–
- Multiple page links (forces pp. prefix unless
|nopp=y;|pageurln=matches the last of|pagen=or|pagesn=or|atn=) –
- Multiple page links (forces pp. prefix unless
While two possible multiple page link handling methods are described, only one should be implemented.
- Categories
- Category:Pages using citations with a url in a page parameter – for citations where
|page=,|pages=, or|at=contains a url:|page=[http://example.org&pg=PA27 27] - Category:Pages using citations with pageurl errors – for citations with
|pageurl=but without a matching (omitted) or blank|page=,|pages=, or|at=parameter. A blank or omitted|pageurl=is not an error even when|url=is supplied. If both|url=and|pageurl=are supplied, the base url in both must be the same.
website for cite web
Add 'website' as an alias for 'work'. Many editors seem confused by the use of 'work' to indicate the website. -- Gadget850 (Ed) talk 16:28, 6 April 2013 (UTC)
- Done in sandbox. Dragons flight (talk) 19:56, 8 April 2013 (UTC)
prearchive for deadurl
Add |prearchive=yes as an alias to |deadurl=no. Negative logic like setting a parameter to false to enable a feature is foreign to the average editor. 'prearchive' better describes the feature for preemptively archiving the link. -- Gadget850 (Ed) talk 16:30, 6 April 2013 (UTC)
Move toward uniform parameter name style
Add these parameter names to the whitelist. These replace their counterparts which are hyphenated, spaced, underscored, or camelcased. Template documentation should be updated to use these parameter names. The purpose is to move toward uniform parameter-name style. Other variants of these names should then, over time, be deprecated (I can always hope).
['authorfirst#'] = true,
['authorlast#'] = true,
['authornamesep'] = true,
['authorseparator'] = true,
['doibrokendate'] = true,
['doiinactivedate'] = true,
['editorfirst#'] = true,
['editorgiven#'] = true,
['editorlast#'] = true,
['editornamesep'] = true,
['editorseparator'] = true,
['namesep'] = true,
['seriessep'] = true,
['templatedocdemo'] = true,
['transchapter'] = true,
['transtitle'] = true,
—Trappist the monk (talk) 18:27, 6 April 2013 (UTC)
- I agree we are very inconsistent about word separators, either nothing, hyphen, underscore, or space, and moving toward consistency is an excellent goal. That said, I'm not sure that removing the separator actually makes the most sense. For example, would it be easier for users if we consistently supported the use of a hyphen as the preferred word separator in parameter names? I have to think that having some separator is easier to read than having no separator. Dragons flight (talk) 19:19, 8 April 2013 (UTC)
postscript check
Check for 'postscript' with more than one character. I'm seeing some odd stuff inserted. -- Gadget850 (Ed) talk 19:30, 6 April 2013 (UTC)
Check for uri scheme in url parameters
One of the more common url errors is the omission of the uri scheme in |url=-type parameters.
{{cite web |url=www.example.com |title=Missing scheme |accessdate=2013-04-10}} → [www.example.com "Missing scheme"]. Retrieved 2013-04-10. {{cite web}}: Check |url= value (help)
CS1 can check for this and report an error |url= requires http:// and categorize into Category:CS1 url missing uri scheme errors or some such.
—Trappist the monk (talk) 11:29, 10 April 2013 (UTC)
- See Help:External link icons for the list of supported URIs. -- Gadget850 (Ed) talk 11:32, 10 April 2013 (UTC)
- "requires http://" would not be appropriate phrasing; as another scheme may apply. Were that not the case, we could programmatically apply http://. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:38, 10 April 2013 (UTC)
- Ok, how about this:
|url=missing URI scheme?
- Ok, how about this:
- —Trappist the monk (talk) 11:53, 10 April 2013 (UTC)
- OK, but it is URI scheme. Note to implementer:
news:andmailto:do not require the//. -- Gadget850 (Ed) talk 12:02, 10 April 2013 (UTC)
- OK, but it is URI scheme. Note to implementer:
- —Trappist the monk (talk) 11:53, 10 April 2013 (UTC)
- Ok, changed.
- Given the reality of URI schemes, I think the best we are likely to do is check that a URL either starts with "//" (protocol relative URLs) or has a ":" occurring in it somewhere. That covers most uses though it wouldn't catch the case of a bad "scheme", like htp://www.foobar.com/. Dragons flight (talk) 20:20, 10 April 2013 (UTC)
- Check added in sandbox. Dragons flight (talk) 23:32, 10 April 2013 (UTC)