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. -- Gadget850 (Ed) talk 09:44, 2 April 2013 (UTC)
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)
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)
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.