View source

From ISFDB

for Rules and standards discussions/Archive/Archive17
You do not have permission to do that, for the following reasons:
You do not have permission to edit pages in the Page namespace.
The action you have requested is limited to users in one of the groups user, Write.
You can view and copy the source of this page:
{{R&S Archive Header|date= January - December 2019}}

== Question 1: "uncredited" versus "unknown" for old manuscripts ==

Is there a strong preference, one way or the other, as to whether authors whose names have been lost to time, because the copyists of medieval manuscripts did not see fit to record them, should be in the database as "uncredited" or "unknown"? Most of these old works have their canonical author as "uncredited" but [http://www.isfdb.org/cgi-bin/title.cgi?1754129 Sir Orfeo], for one, is "unknown." --[[User:Vasha77|Vasha (cazadora de tildes)]] 21:08, 7 January 2019 (EST)
:Uncredited should be used if the original work was not credited. Unknown is for use when you are using a secondary source that doesn't specify the author, but doesn't necessarily mean the author is uncredited. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 21:25, 7 January 2019 (EST)
:: If no one disagrees with this, I will go through and find all the "unknowns" and correct them to "uncredited." --[[User:Vasha77|Vasha (cazadora de tildes)]] 21:47, 7 January 2019 (EST)
:::My statement is per the help (see [[:Template:TitleFields:Author]], bullet 1). However, your "''I will go through and find all the "unknowns" and correct them to "uncredited."''" is ambiguous. I hope you mean only ones that match the case you mentioned above. Because there are valid "unknowns" in the database. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 22:46, 7 January 2019 (EST)
:::: Well yeah, I meant "Sir Orfeo" and any others that may have the same mistake. --[[User:Vasha77|Vasha (cazadora de tildes)]] 23:01, 7 January 2019 (EST)

:::: Update: I spoke too soon—there are evidently a LOT of things that need correcting on the [http://www.isfdb.org/cgi-bin/ea.cgi?2862 unknown] summary page, and the task of figuring out which ones to correct is beyond me. However, at least now I know what should be done; and I did find and change a few obvious ones.  --[[User:Vasha77|Vasha (cazadora de tildes)]] 23:15, 7 January 2019 (EST)
:::::The bulk of the records are house names where the true writer is not known. That is a valid use. I fixed a couple of obvious errors. I'm sure there are more, but not convinced it's a lot of things. Most of the non-house names that I spot checked were valid uses. I do have it on my list to cleanup some of the 'Noname' house name ones as any of the Frank Reade Jr.'s are by Luis Senarens per SFE3. While the Frank Reade's were done by multiple people, the Jr.'s were all done by Senarens. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 18:51, 8 January 2019 (EST)

:::::: Probably those Arabian Nights records should be "uncredited" but I'd really like to look at the publications to see exactly how they're credited. There are a couple dozen more folktales and old stories ... Yes, the house names make up 85% of it, but the rest needs checking. --[[User:Vasha77|Vasha (cazadora de tildes)]] 19:10, 8 January 2019 (EST)

== Question 2: Dates of literature from manuscripts ==

What should be the date, in this database, of literature whose first extant copy is a manuscript that can't be precisely dated? The majority of them currently have the date "unknown" (0000-00-00) but some, like [http://www.isfdb.org/cgi-bin/title.cgi?1951339 Clerk Saunders], are listed according to a date when they were printed; and [http://www.isfdb.org/cgi-bin/title.cgi?1457625 Sir Gawayn and þe Grene Knyȝt] has been given the date 1400-00-00 because that is the approximate date of the manuscript. 

For the record, I'm in favor of continuing the practice of the majority. It's not unreasonable to regard the manuscript as a publication. Discussion of the date of composition and dates of manuscripts can be a paragraph in the notes, and a date of "unknown" lets visitors know to look at the notes for more information. --[[User:Vasha77|Vasha (cazadora de tildes)]] 21:46, 7 January 2019 (EST)

: I guess it depends on how we define "publication". For example, we think of books printed by book clubs as "published" even though technically only book club members have access to them. Another example: back in the day some books were "privately published" for a select group of subscribers, kind of an early version of the "limited edition" concept. We consider them "published" even though 99.999% of the public had no access to them.

: Prior to the invention of the printing press, manuscripts were arguably "published" if numerous copies existed. However, where do we draw the line? What if only 3 copies of a particular manuscript were made? 2? 1? And how can we be sure that the number of currently known copies is not a fraction of the total number of copies made? [[User:Ahasuerus|Ahasuerus]] 22:00, 7 January 2019 (EST)

:: Indeed, I guess "Clerk Saunders" is not very relevant to this discussion because it doesn't predate the printing press; it first appeared in a couple of 18th-century manuscripts (private notebooks) that were definitely not intended for circulation. But the case of medieval manuscripts is different: even if few copies were made (or even one!), they were usually still intended to be part of a library. I think we should gloss over the complexities of production and use by considering manuscripts prior to 1500 or so to be publications ... --[[User:Vasha77|Vasha (cazadora de tildes)]] 22:18, 7 January 2019 (EST)

== Revisiting conflicting policies about nongenre works ==

Last year, in the course of a [http://www.isfdb.org/wiki/index.php/ISFDB:Help_desk/archives/archive_27#Including_nongenre_titles_in_partial_contents discussion] about a somewhat different matter, I pointed out that two of the ISFDB policies conflict with each other: 1. [[ISFDB:Policy]] says that we exclude "Works that are not related to speculative fiction by authors who have not published works either of or about speculative fiction over a certain threshold." 2. We include the complete contents of genre magazines; I can't find where this is written in policies, but during last year's discussion, everyone agreed that this is our practice. Obviously, these two rules are contradictory: do we include or exclude a non-speculative work by a non-genre author that appears in a genre magazine? --[[User:Vasha77|Vasha (cazadora de tildes)]] 15:09, 17 January 2019 (EST)

: I'll need to do more digging, but there is a relevant paragraph in [[Help:Entering_non-genre_periodicals#Genre_special_issues]] -- see the bolded part:

:* Sometimes, a non-genre periodical will devote an entire issue to speculative fiction and/or articles about it. This can be regarded as '''a genre publication and genre non-fiction should be cataloged along with the fiction''' (even though we do not normally catalog non-fiction from non-genre magazines).

: [[User:Ahasuerus|Ahasuerus]] 14:33, 18 January 2019 (EST)

In the discussion I'm citing, no one had any suggestions as to what to do about resolving this problem. But I've since had some thoughts that might help add clarity.

An appearance in a genre magazine is not the only reason a non-genre story might legitimately be in the database. As you all probably know, some of our standard secondary sources, such as the Supernatural Index, included anthologies that contained a mixture of speculative and non-speculative stories, and indexed their entire contents without indicating which of the stories weren't actually speculative. Other writers then copied from them when creating lists of speculative fiction, not realizing that they were including non-genre works in the list. I see this as a good reason to include in the DB the complete contents of any anthology indexed by the Supernatural Index et al. (with NG items marked as such): we will be setting the record straight, and it will be useful for someone to be able to look up everything in one of these "speculative" lists and find it here. "Huh, why is ''this'' on the list? Oh, because of being in such-and-such anthology."

That's two potential reasons to make an exception to the principle "exclude ng works by ng authors." Perhaps we need to rewrite that policy; what do you think? It could be an "include only if" rule in three parts: "Include nongenre works only if 1. They are by an author above a certain threshold; or 2. They have been published in a genre magazine; or 3. They are listed in one of the standard secondary sources." (Or, whatever reasons for including ng works we agree on; the main point is that we can rewrite the policy so that "author above threshold" is no longer stated to be the only possible reason for inclusion of an ng work.) --[[User:Vasha77|Vasha (cazadora de tildes)]] 15:09, 17 January 2019 (EST)

: The last time the issue came up, [[ISFDB:Community_Portal#Some_absent_Theodore_Sturgeon_reviews|I made a comment that may be relevant]]:

:: (reformatted) One of the problems that we have run into when discussing what types of non-fiction to include is the sheer number of different ways to categorize them. Off the top of my head:

::* Length: books vs. short works. Short works are further subdivided into:
::** Essays
::** Reviews
::** Interviews
::* Type of publication where the non-fiction work appeared:
::** Genre periodicals
::** Non-genre periodicals
::** Genre books
::** Non-genre books
::* Type of non-fiction work:
::** Works about written SF
::** Works about non-written SF like comics, films, TV, etc
::** Works about non-genre issues
::** Works that are "sort of" related to SF, e.g. space exploration, history of myths, etc

:: This segmentation makes it difficult to ensure that everyone is on the same page when discussing proposals that cover only certain "cells" of this multidimensional matrix. Perhaps a graphical (tabular?) representation may help clarify what our policy currently says and where we may want to go from here. [[User:Ahasuerus|Ahasuerus]] 16:44, 16 December 2018 (EST)

: Getting back to the issue of non-genre fiction, I agree that we need to -- at the very least -- clarify Help. [[Template:PublicationInfo:WhatToInclude]], which is transcluded in [[ISFDB:Policy]] and [[Help:Screen:NewPub#Content_Information]], was originally written based on the assumption that it would be used when entering genre publications. A significant part of the template primarily applies to genre magazines. We should make these assumptions explicit and also add a bidirectional link to [[Help:Entering_non-genre_periodicals]] in order to eliminate/reduce ambiguity. [[User:Ahasuerus|Ahasuerus]] 15:32, 18 January 2019 (EST)

:: I think that Vasha is talking about non-genre FICTION here though. While we need to resolve both, I think the bigger issue are non-genre stories and not non-fiction. Or I am badly misreading things :) [[User:Anniemod|Annie]] 15:56, 18 January 2019 (EST)

::: Rereading my comment above, I see that it wasn't very clear. It consisted of two parts. The first part was a repost of my December 2018 comment about non-fiction. The second part, which starts with "Getting back to the issue of non-genre fiction", was about non-genre fiction. [[User:Ahasuerus|Ahasuerus]] 16:18, 18 January 2019 (EST)

:::: Now that you mentioned it - now i see that it is two parts - the second one looked almost as an afterthought so I think I got stuck on the first one. :) [[User:Anniemod|Annie]] 16:24, 18 January 2019 (EST)

::::: I wasn't talking about non-fiction at all; I meant FICTION that is non-genre and has no speculative elements, and I guess I should have made that more clear in the title of the post. The way the Rules of Acquisition are currently worded, they lump fiction and non-fiction together. Both of them are referred to by the paragraph in "Exclusions" that says "Works that are not related to speculative fiction ..." Maybe this whole section of the Rules of Acquisition needs to be rewritten to discuss fiction and nonfiction separately? We do seem to have different standards for the two. --[[User:Vasha77|Vasha (cazadora de tildes)]] 16:46, 18 January 2019 (EST)

:::::: It looks like there are two issues here:

::::::# Cleaning up the Rules of Acquisition and Help to bring them in line with our current practices (while making sure that everyone is on the same page re: what the current practices ''are'')
::::::# Using "the standard secondary sources" as the guide when deciding whether to include non-genre works

:::::: Naturally, I am all in favor of #1, but I have my doubts about #2. If nothing else, different bibliographers can use different inclusion criteria when compiling different bibliographies. There will be times when their criteria will be similar to other bibliographers' (including ours) but there will also be times when they will be different.

:::::: To take a step back and look at the big picture, the main reason why the issue of what's included and what's excluded is so complicated is that we use two different types of eligibility criteria. On the one hand, we have a list of criteria which determine where we draw the line between "speculative fiction" and other types of texts (or "titles" as we call them.) It can be tricky, but ultimately we can make it mostly consistent. On the other hand, we have another list of eligibility criteria based on ''publication'' data. The basic idea was that we wanted to:

::::::* exclude things the [https://www.fanfiction.net/book/ 801,000 Harry Potter fanfics hosted by FanFiction.net] even though they are SF, and
::::::* include [http://www.isfdb.org/cgi-bin/title.cgi?2284081 "Major Pugachov's Last Battle"] even though it has nothing to do with SF, but ''only'' when it appears in a "genre publication"

:::::: Once we added publication-based criteria to the mix, things became complicated.

:::::: I think it would be best to clarify and clean up Policy and Help first. We made some progress last year when many "Debatable" lines were sorted out and I hope that we can make more progress in the coming months. Clarifying what counts as a "genre publication" and updating Policy/Help with guidelines re: handling genre and non-genre publications may be a good first step. [[User:Ahasuerus|Ahasuerus]] 11:25, 19 January 2019 (EST)

::::::: To the idea of cleaning up the Policy and Help, a thousand times yes. As you say, the publication-based criteria add considerable complexity. And that is presumably why they are not currently discussed in the RoI even though people are using them. We should have a comprehensive discussion about what the practices are. 

::::::: It's interesting that you cite "Major Pugachov's Last Battle" as an example: that one's not even in a genre magazine, but in genre anthologies! During last year's discussion, more or less 100% of contributors supported indexing the complete contents of genre magazines, but were uncertain about anthologies. And I can see why: deciding what's a genre anthology is a problem that would puzzle the planet's best minds; magazines are a considerably more defined and constrained set (though naturally there are uncertain cases). At any rate, any revision of the RoI will have to mention this principle about the contents of magazines. --[[User:Vasha77|Vasha (cazadora de tildes)]] 13:02, 19 January 2019 (EST)

:::::::: Let me quote [[Help:Entering non-genre periodicals]] to make sure that we are on the same page re: what Help currently says:

::::::::* Anthologies that contain mostly general fiction, but also have some SF content, can also be entered using the data entry rules for non-genre periodicals.

:::::::: The way it's phrased -- note the word ''can'' -- is somewhat ambiguous. Based on the principle "one headache at a time", I decided not to open this can of worms and leave the sentence "as is" when I was updating the page last year.

:::::::: My current thinking is that it would be a good starting point for a discussion. If we can define "genre publications" and "non-genre publications", it would establish a solid foundation for future Policy/Help updates. [[Help:Entering non-genre periodicals]] already mentions the concept of "genre publications" under [[Help:Entering_non-genre_periodicals#Genre_special_issues]], but it needs to be fleshed out. [[User:Ahasuerus|Ahasuerus]] 19:43, 19 January 2019 (EST)

::::::::: That is a can of worms, all right. Note that "using the data entry rules for non-genre periodicals" might imply that we entered the editors as "Editors of..." and some people had formerly done so until a discussion last year (I wish I could find it) made clear that a solid majority were opposed to it.  So that's one way that practices for anthologies differ from magazines. But, I guess I will move this discussion into a separate section to see what people think now. --[[User:Vasha77|Vasha (cazadora de tildes)]] 21:19, 19 January 2019 (EST)

::::::: One reason the Policy page is currently confusing is that it is not made clear exactly which works the "What to Include" section is referring to. Its description just says "This section will help editors to determine whether a contained work should be entered as a separate content record in a ISFDB publication record." But then it goes on to say, "All forms of fiction are always included," which is in contradiction to the sentence in the Rules of Acquisition one paragraph above, to exclude "Works unrelated to speculative fiction that are found in primarily non-genre publication [''sic''] that will be cataloged based on other criteria, e.g. ... a Playboy issue that include a single speculative story ..." So tacitly, the "What to Include" is not dealing with these "primarily non-genre publications". We need to make that explicit, and be more clear about what "primarily non-genre publications" are.  --[[User:Vasha77|Vasha (cazadora de tildes)]] 13:02, 19 January 2019 (EST)

=== Anthologies with little spec fic: interpreting what "Help" says ===

(copied from above) Help currently says:

Anthologies that contain mostly general fiction, but also have some SF content, can also be entered using the data entry rules for non-genre periodicals.

The way it's phrased -- note the word ''can'' -- is somewhat ambiguous. Based on the principle "one headache at a time", I decided not to open this can of worms and leave the sentence "as is" when I was updating the page last year.

My current thinking is that it would be a good starting point for a discussion. If we can define "genre publications" and "non-genre publications", it would establish a solid foundation for future Policy/Help updates. [[Help:Entering non-genre periodicals]] already mentions the concept of "genre publications" under [[Help:Entering_non-genre_periodicals#Genre_special_issues]], but it needs to be fleshed out. [[User:Ahasuerus|Ahasuerus]] 19:43, 19 January 2019 (EST)

: That is a can of worms, all right. Note that "using the data entry rules for non-genre periodicals" might imply that we entered the editors as "Editors of..." and some people had formerly done so until a discussion last year (I wish I could find it) made clear that a solid majority were opposed to it.  So that's one way that practices for anthologies differ from magazines. 

: The way it would look if we treated a not-primarily-genre anthology ''exactly'' like a magazine issue would be: it would be marked NG, we would only catalog speculative ''fiction'' contents even if there are speculative-related essays, we would not create art records for it unless the art is directly related to a piece of speculative fiction in it, and the editors would be listed as "Editors of ..." Does all that make sense? --[[User:Vasha77|Vasha (cazadora de tildes)]] 21:19, 19 January 2019 (EST)

:: We need to be very careful around that specific point - 10 years ago magazines and anthologies were easy to separate. These days? Half of what is being published by the small presses can be categorized either way - and sometimes what it looks like changes a few issues into a run. Just saying :) [[User:Anniemod|Annie]] 14:48, 20 January 2019 (EST)

::: Heck yeah, the line is blurred in all sorts of ways—a lot of annual journals are in the DB as anthologies, for example, and [https://foreshadowya.com/about Foreshadow], which calls itself a "serial anthology" and plans to publish once a month for exactly one year, is in the DB as a webzine. It would certainly make life much easier if we applied ''exactly'' the same standards to the two, so that we wouldn't have to rethink anything if we changed the type from one to another. Or at least, if preferred, the same standards except for the "editors of" thing; that at least would be easy to convert from name to "Editors" or vice versa if changing the type. --[[User:Vasha77|Vasha (cazadora de tildes)]] 14:57, 20 January 2019 (EST)

:::: I agree that standardizing the data entry rules for non-genre anthologies and non-genre magazine -- to the extent possible/feasible -- would be a step in the right direction. Currently we handle editor attribution differently. Anything else that we do differently for non-genre anthologies vs. non-genre magazines? (I am under the weather at the moment, so I may be missing something obvious.) [[User:Ahasuerus|Ahasuerus]] 18:42, 20 January 2019 (EST)
(unindent) Cover art. The non-genre periodical help page states that cover art should not be entered (credit or image) unless it illustrates genre contents. There is not a similar restriction for non-genre anthologies and common practice is to include it. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 19:55, 20 January 2019 (EST)

: Oh, right. Thanks! [[User:Ahasuerus|Ahasuerus]] 20:34, 20 January 2019 (EST)

:: Huh, I wasn't aware of that common practice, and I've been omitting cover art from NG anthologies. It's not much of a loss, is it? --[[User:Vasha77|Vasha (cazadora de tildes)]] 20:43, 20 January 2019 (EST)
::: Usually not, though I included cover art for those images that include speculative content or are by notable spec. artists. It ''is'' complicated. [[User:Stonecreek|Stonecreek]] 03:37, 21 January 2019 
::::Interesting... We have a guideline to not do magazine cover art for ng mags unless it ''illustrates'' a story, but a practice to usually include antho cover art. Those of you who make this distinction, how do you feel mags and anthos differ? What is it about ng magazines that makes you feel you should omit general speculative art, which you don't feel about ng anthologies? --[[User:Vasha77|Vasha (cazadora de tildes)]] 05:32, 21 January 2019 (EST)
:::::[[Rules_and_standards_discussions/Archive/Archive14#Non-Genre_Magazine_Cover_Art|This conversation]] left me with the impression it has to do to with the type of covers some magazines have (which is typically not an issue for anthologies). --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 08:01, 21 January 2019 (EST)
:::::: Not sure what you mean--are you referring to the comment about not wanting to host ''Playboy'' covers? There most certainly are erotic anthology covers, speculative as well as non. --[[User:Vasha77|Vasha (cazadora de tildes)]] 09:23, 21 January 2019 (EST)
:::::::I believe I have seen other similar comments. Whether it is the quantity difference or something else, you would have to ask those that espoused that opinion. But either way, it is something that should be thought through and dealt with (for both non-genre & genre, magazines & non-magazines) in a consistent way (don't allow, allow, allow with filter, other). --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 11:00, 21 January 2019 (EST)

:::::::: Setting aside the question of whether to filter erotic images, I see no need to have cover images for nongenre magazines, and doubly no need for artist records. But there seems no reason to have them for nongenre anthologies either. Can we not unify the standards? --[[User:Vasha77|Vasha (cazadora de tildes)]] 13:16, 21 January 2019 (EST)

(unindent) And we still do need some standardization: when does an anthology earn the spec. fic. category? My rule of thumb was that more than half of the fiction items should be in that vein, but does that mean in number, in volume / page count, or in one of those? [[User:Stonecreek|Stonecreek]] 03:37, 21 January 2019 (EST)
: Either or both of those; in the doubtful indeterminate area, you can be influenced by what the editors state is the theme and emphasis of the work. --[[User:Vasha77|Vasha (cazadora de tildes)]] 06:27, 21 January 2019 (EST)

:: I find that in most cases the intent is clear and the clear majority of included stories is either SF or non-SF. The main exceptions are horror anthologies/collections which include both supernatural horror and psychological horror stories. Also, some "cross-genre" anthologies like [http://www.isfdb.org/cgi-bin/pl.cgi?358621 ''Not to Be Taken at Night: Thirteen Classic Canadian Tales of Mystery and the Supernatural''] require additional digging to determine which stories are SF. The worst offender that I have come across recently is [http://www.isfdb.org/cgi-bin/pl.cgi?258788 ''The Fatal Eggs and Other Soviet Satire: 1918-1963'']: the title novella is SF, but I have been unable to determine whether the rest are (some appear to be satirical fabulations.) [[User:Ahasuerus|Ahasuerus]] 14:52, 21 January 2019 (EST)

::: Yes! "mystery and the supernatural" anthologies are a headache; some editors who had their anthologies marketed in that category had a heavy emphasis on non-supernatural suspense, adventure, and melodrama, whereas others were mostly interested in speculative fiction with some non-supernatural weird fiction thrown in; and it can be really hard to know which is which without looking at the book itself. The famous example is ''Great Tales of Terror and the Supernatural'' (1944), the section labelled ''terror'' covers both spec and nonspec. I think that from about 1900 to the 1950s you had mixed spec/nonspec "mystery" anthologies and "terror" anthologies; I think the former term implies less supernatural fiction than the latter, but really the usage overlapped. --[[User:Vasha77|Vasha (cazadora de tildes)]] 15:30, 21 January 2019 (EST)

::: BTW, re: ''The Fatal Eggs and Other Soviet Satire''; my local university library has it & I'll look at it tomorrow. --[[User:Vasha77|Vasha (cazadora de tildes)]] 16:22, 21 January 2019 (EST)

:::: Thanks! [[User:Ahasuerus|Ahasuerus]] 16:36, 21 January 2019 (EST)

=== Help Cleanup: Proposed First Step ===

After reviewing various related Help pages, I think it may be best to start with [[Help:Entering non-genre periodicals]]. It's wordy, repetitive and duplicates many of the rules found in our main Help templates. I suggest that we start by eliminating duplication and compressing the rest to something more manageable. Ideally, we'll reduce it to a list of differences between the data entry rules for genre and non-genre publications. That should make it easier to understand what the currently documented differences are; then we can decide what to do about them. [[User:Ahasuerus|Ahasuerus]] 15:42, 21 January 2019 (EST)

== How to reference pages preceding page 1? ==

(Moved discussion over from Helpdesk) [http://www.isfdb.org/wiki/index.php/ISFDB:Help_desk#How_to_reference_pages_preceding_page_1.3F Referencing pages]

The current rules on page count and page referencing as explained [http://www.isfdb.org/wiki/index.php?title=Template:PublicationFields:Pages here], [http://www.isfdb.org/wiki/index.php/Help:How_to_determine_the_value_for_the_%22Pages%22_field_in_a_book here] and especially [http://www.isfdb.org/wiki/index.php/Help:Screen:EditPub#Page here] state that
<ol><li>Total page count is calculated by adding all numbered and unnumbered page ranges, provided they have contents that need to be recorded. For example [10]+400+[15], where there are unnumbered pages before and after the body of the work. This is fairly straightforward.
<li>Referencing pages within the pre- or post unnumbered pages is done by means of the derived page number <em>within that page range</em>. This is not so straightforward and the rules are not easy to understand.
</ol>

As far as I can tell the current rules are ambiguous in cases such as the [10]+400+[15] example above: if you refer to page [5], which one is it? Is it the 5th page of the unnumbered page range '''before''' or '''after''' the body text?

Solution applied by some editors (including me) for the 'after' bodytext case is to derive page numbering based on the last printed page number and then counting forward. My example would then be page [405] as referring to the 5th unnumbered page of the unnumbered page range following the bodytext.

This approach breaks down for an unnumbered page range ''before'' the bodytext of course (unless we go with negative page numbers!). A solution editors have come up with for the 'before' bodytext case is to use roman numerals for both page count as well as page number, and adding a clarifying note. For the above example this would translate to: total no of pages [x]+400+[15] for the total page count, and the contents on page 5 of the unnumbered page range before the body text would then be referred to as [v]. See {{p|703038|Senlin Ascends}} for an illustrative example.

Is there anyone else that has struggled with this and has come up with a cleverer solution? Can we improve or strengthen the current rules somehow? 

And we also need to come up with an explicit rule for counting the total number of unnumbered pages before page 1. Do we start counting from the very first page (not counting the cover), or do we start counting backwards from page 1 until the relevant piece(s) we want to record the page number(s) of? I guess the former is the right way to count, but the rules don't really confirm that. (And I've used the latter in my earliest edits...) [[User:MagicUnk|MagicUnk]] 14:34, 2 February 2019 (EST)
:To my novice mind, using [bracketed] roman numerals for the unnumbered pre-pages makes the most sense, and it seems to me offhand that that wouldn't cause any problems. The only problem that would leave was if there were unnumbered pages before numbered roman numerals before regular numerals. It http://www.isfdb.org/wiki/index.php?title=Template:PublicationFields:Pages  doesn't specifically say not to use roman numerals for unnumbered pages. gzuckier 17:22, 2 February 2019 (EST)
::The purpose of the content page numbers is a) to differentiate publications and b) give a rough idea of size. I don't think there would really be any confusion with the [5] in the example above. It's insufficient information to recreate the publication, but certainly enough to tell if the pub you hold matches the description. ../[[User:Holmesd|Doug H]] 20:05, 2 February 2019 (EST)
:::I agree with Doug and don't see a need to change the numbering system.  We don't worry about this with multi volume publications which can have multiple instances of any page.  In those instances, we use the pipe (|) operator to force the numbering to the right place in the contents list.  So for first page of the unnumbered pages preceding the pagination we could enter it as "[1]|0.01", page 1 in volume 1 would be simply "1" and page 1 of volume 2 would be "1|2001".  There really isn't a need to introduce bracketed roman numbers which would necessitate changing those publications entered under the current system.  --Ron ~ [[User:Rtrace|Rtrace]]<sup>[[User talk:Rtrace|Talk]]</sup> 22:21, 2 February 2019 (EST)

::::I do not agree with Doug that we should be satisfied with insufficient or incomplete information. I believe that when providing information we need to be as specific and unambiguous as we can. <br>Anyhow, as for Ron's remark referencing page numbers per the current rules is unambiguous only when page order (by using the piping symbol) AND page count information is both available. In other words it only works for contents listed in the contents section that have page numbers & ordering added to them. It still does not work if you want to refer to pages that are not recorded as contents but one still wants to capture - see Stonecreek's example {{p|535387|here}}. Granted, we could spell out in the notes field something like 'on unnumbered page [5] preceding page 1' or some such when we want to refer to a specific unnumbered page. It would be strictly following the current rules but it's quite elaborate that way. Nevertheless, we could do it that way and it would work.
::::So, do we agree that <br><ol><li>We consequently continue to use roman numerals for page count for unnumbered page ranges before AND after the body text, in conjunction with contents page number and page order (as the current rules dictate), and <li>When referring in the notes to unnumbered pages from page ranges before or after the body text that are not entered as contents record we explicitly mention which page range that particular page is from?</ol>

::::If we agree this is the way to continue it would mean that moderators need to be more attentive to ensure the rules as they are are correctly followed by editors because they -are- confusing and its finesses not easy to grasp. It would also mean that a lot of entries are strictly speaking incorrect per the rules and are to be updated. {{p|535387|Stonecreek's example}} is one to correct, and {{p|703038|this one}} too. [[User:MagicUnk|MagicUnk]] 10:32, 3 February 2019 (EST)

:::::Neither of the two examples you cite follow that standards and in the case of {{p|535387|Gypsy plus ...}}, it's particularly confusing.  First off, since there are no brackets around the roman numbers in the pages field, I can't tell if there are 10 actual pages with roman numbers or not.  There is no content listed on these pages, so they should only be included in the Pages field if the pages are actually numbered.  The same goes for the "+[1]" page after  the main page numbering.  Again, we're not listing anything in the contents section, so they shouldn't be noted in the Pages field.  Now, for the content indicated only in the notes preceding the 10 pages preceding the numbered pages, I think we would be better served by describing the pages.  The note stating that the title is taken from page v, would seem to indicate that "page v" is the title page.  If so, that's standard and need not be noted.  If page v is something other than the title page, then the note should be expanded as to why the title is taken from that page instead of from the title page.  I'm unsure of what is meant by "more feature contents" on "page vii".  Is it a table of contents, or is "feature" a typo for "future" and it's really a list of forthcoming books?  Neither of those items are significant enough that we need to reflect which page they occur on.  Personally I wouldn't bother noting either, but stating that the TOC or a list of forthcoming books appear "after the title page" would seem sufficient.  I'm also not clear on what "pp. 143ff" refers to.  Assuming the "ff" is a typo, that's within the regular numbered pages.  The bibliography and the  About the Author essay could be listed in the main contents section.  Adding the latter would make "+[1]" appropriate, in which case it should be entered as being on page [146].
:::::The only non-standard usage in {{p|703038|Senlin Ascends}} is the use of "[xii]" instead of [12] and the corresponding  listing of content on page "[ix]" instead of "[9]|0.09".  I just don't see any advantage to changing the standard from Arabic to roman numbers  to indicate unnumbered pages.  I wouldn't want to go back and revisit everything that has been entered according the existing standard without a good reason for doing so.  --Ron ~ [[User:Rtrace|Rtrace]]<sup>[[User talk:Rtrace|Talk]]</sup> 18:51, 3 February 2019 (EST)

::Well, the "+[1]" page is caused by the section in the help of "Contents included with exceptions": it shows there is a content, but it's not listed as own entry but only in the notes. This, as the explanation for the Roman numerals is explained within the notes. At that time, it seemed better to me to have the preceding pages shown in the page count for the publication, but it would pose no problem for me to alter this. Christian [[User:Stonecreek|Stonecreek]] 02:44, 4 February 2019 (EST)

::: OK, what I've done is update two pub records and applied the page count & page reference rules as they currently exist. {{p|654579|Arm of the Sphinx}} has a before and after unnumbered page range, and {{p|654179|Wonderblood}} has a before roman numeraled page range. Can you have a look and tell me if this makes sense and is per the current rules according to you? Pay special attention to the notes where I used the phrases ''before page 1'', and ''at the end of the publication'' to refer to the relevant section. And looking at the contents of {{p|654579|Arm of the Sphinx}} I still find it awkward to do it that way... Anyone a better/other proposal? [[User:MagicUnk|MagicUnk]] 13:48, 5 February 2019 (EST)

::::The problems I see with {{p|654579|Arm of the Sphinx}} is that you have started the numbering over for the post numbered page contents.  Per the first bullet after "Pages without a printed page number" in [[Help:Screen:EditPub#Page|this help section]]: "If the page is not numbered, and is within a range of numbered pages (i.e. the pages which follow the first numbered page within a publication), its page number can be derived from the nearest numbered page.", thus the interview can be entered on page 405 and the excerpt on page 411, assuming the novel ends on page 398.  The rest looks good.  For {{p|654179|Wonderblood}}, I probably would have entered the pages as "vii+285" as the highest roman numbered page is vii.  If you want to reflect the individual illustrations, they should be entered in the contents section and not in the notes.  The titles would be "Wonderblood", "Wonderblood [2]", etc.  Their page numbers occurring on unnumbered pages could be derived.  If you only want a single INTERIORART record for all the illustrations it shouldn't be disambiguated.
::::For the former, you can see why I don't think we need to change to bracketed roman numerals for unnumbered pages preceding those that are numbered.  There really shouldn't be any confusion as to where something occurs.  --Ron ~ [[User:Rtrace|Rtrace]]<sup>[[User talk:Rtrace|Talk]]</sup> 19:32, 5 February 2019 (EST)

::::: Hi Ron. The issue, I think, we're having is is that it is not clear whether unnumbered pages at the end of the publication is to be considered ''within a range of numbered pages' or not.
::::: I read [[Template:PublicationFields:Pages|here]] that ''...you may record the count of unnumbered pages at the end of a publication. For example, 320+[4]...''. So far so good.
::::: Then I go on to read [[Help:Screen:EditPub#Page|here]] that (2nd bullet) ''If a content starts on an unnumbered page within a range of unnumbered pages, its page number should first be derived and then entered in squared brackets.'', and ''...if a content appears on the fifth page in a range of unnumbered pages, enter "[5]".'', and finally ''Do not use brackets for unnumbered pages which fall within a range of numbered pages.''
::::: In my mind {{p|654579|Arm of the Sphinx}} interview etc. are contained in 'Unnumbered pages within a range of unnumbered pages'' that come after the numbered range containing the text of the novel proper, so are covered by the second bullet, whereas you infer that the interview etc. are contained in ''Unnumbered pages within a range of numbered pages'', which would require to continue counting, and using the page reference as you suggest. 
::::: So question is, how do we determine pages are either within the range of numbered pages, or are outside the range of numbered pages, hence require the second bullet to apply? [[User:MagicUnk|MagicUnk]] 07:03, 6 February 2019 (EST)
::::::The definition is in the first bullet of the same section.  I quoted this above: "If the page is not numbered, and is within a range of numbered pages (i.e. the pages which follow the first numbered page within a publication)...".  The second bulleted paragraph even refers back to the first for the definition: "Do not use brackets for unnumbered pages which fall within a range of numbered pages. (See the first bullet under this subsection.)"  Even if we were to ignore these definitions, what would be the point of adding another series of numbered pages at the end of the book?  We already know which pages are unnumbered from the pages field.  Numbering them in the manner that you have only introduces the confusion between the defined unnumbered section (before any page numbers) and the rest of the book, which I believe is what your proposal is trying to address.  --Ron ~ [[User:Rtrace|Rtrace]]<sup>[[User talk:Rtrace|Talk]]</sup> 19:11, 6 February 2019 (EST)
::::::: So, what you are saying is that for unnumbered pages at the end of a pub the second bullet never applies as they willl always fall within the range of numbered pages preceding them, and consequently we are not allowed to use square brackets to refer to these unnumbered pages because they 'belong' to the preceding section as per the first bulllet? [[User:MagicUnk|MagicUnk]] 23:17, 6 February 2019 (EST)
:::::::: I've reread those help sections and I can see how you might interpret them as you do.  Given the two interpretations, I believe that maintaining the Arabic numbering through the end of the book works best.  Restarting the numbering sequence, or placing page numbers in square brackets at the end of the book servers no purpose that I can see.  --Ron ~ [[User:Rtrace|Rtrace]]<sup>[[User talk:Rtrace|Talk]]</sup> 19:33, 7 February 2019 (EST)

(Unindent) True. Continuously numbering unnumbered pages that appear after the main text was what I've been doing up to now, but now I suspect that this is very much against (the intent of) the current rules. Shall we discuss rules clarification, or do we finish the front/back coverart discussion first? ;) [[User:MagicUnk|MagicUnk]] 01:38, 8 February 2019 (EST)

== Tagging Inactive users ==

I don't see any rules for if and when we should hat-notice another user's talk page with [[Template:Inactive user]].  For example, [[User:Dragoondelight]] was last active on 2010-12-01. On 2012-11-03, or 23 months later, Mhhutchins tagged the person as inactive.

[[User:Syzygy]] has been inactive since 2016-10-28. On that date, as part of a reply about a publication question the user included, "I am taking a small break from editing." The break is now at almost at 29 months.

What I would like to see is a note on [[Template talk:Inactive user]] with rules or guidelines on if and when an editor should add the template to another user's talk page. If a break is planned, the note should encourage self-tagging, such as what [[User talk:Hauck|Hauck]] did on 2018-06-29 which was also that user's last-active date. --[[User talk:Marc Kupper|Marc Kupper]] 14:44, 24 March 2019 (EDT)

: I see two separate issues here.

: The first one is technical. There are three different types of "user activity":

:* database submissions
:* Wiki edits
:* publication verifications

: The only way to find the last "user activity date" for a user is to use [http://www.isfdb.org/cgi-bin/adv_user_search.cgi User Search] accessible from the [http://www.isfdb.org/cgi-bin/adv_search_menu.cgi Advanced Search page]. I guess we could create a nightly cleanup report that would:

:* find all users with a Talk page and no "Inactive" template in the body of the Talk page
:* for each identified user check if the last activity date is more than N months in the past, where N is to be determined

: The second issue is procedural. Some people use the ISFDB on a regular basis, but don't edit it very often. Short of recording each user's last ISFDB access date -- which I don't think we would want to do for privacy reasons -- there is no way of telling if a user may be lurking and available to answer questions. [[User:Ahasuerus|Ahasuerus]] 15:18, 24 March 2019 (EDT)

== Synopsis guidelines ==

I was asked about guidelines for writing synopis as someone pointed [http://www.isfdb.org/cgi-bin/title.cgi?45859 this] out to me. Can it have a "judgement"? It's not supposed to be a review. --[[User:Mavmaramis|Mavmaramis]] 23:37, 6 April 2019 (EDT)

: [[Template:TitleFields:Synopsis]] says that:

:* this is not a place for criticism or reviews, and should maintain a neutral point of view.

: A number of statements in the linked synopsis, including "Fred Pohl should have known better", "The dilemma is solved by a stupid fortuitous event", and "By far the worst story by Pohl I have ever read", are incompatible with the Help text. [[User:Ahasuerus|Ahasuerus]] 23:43, 6 April 2019 (EDT)

::Thanks Ahasuerus. Just to be absolutly clear I did not write that synopsis.--[[User:Mavmaramis|Mavmaramis]] 04:25, 7 April 2019 (EDT)

::: Understood. I have removed the spoilers and the commentary. [[User:Ahasuerus|Ahasuerus]] 10:25, 7 April 2019 (EDT)

:::: I have identified the editor who has contributed 189 synopses. A number of them have similar problems, which I'll need to correct. I will leave a note on the editor's Talk page once I am done. [[User:Ahasuerus|Ahasuerus]] 10:38, 7 April 2019 (EDT)

::::: Done. [[User:Ahasuerus|Ahasuerus]] 17:39, 7 April 2019 (EDT)

== Variants for uncredited artwork (covers) ==

For known authors covers are made variants of each other when the have the same artwork (e.g. translations or cover reuse). This especially allows to see where artwork was reused and where and when the original was made. This is not possible for unknown authors.

A few years ago I already asked for a way to link two covers which have no known author, but my proposal to simply add "uncredited" as author and then link the titles like for known authors was rejected. One of the main reasons was the additional load on the "uncredited" author name. Currently a link in the description text is the only solution, but this fails to have all the benefits of "joining" the entries.

Inbetween ISFDB has been changed and "uncredited" is handled specially and no longer shown.

So I do propose again: For uncredited artwork allow the use of "uncredited" for artwork in these cases where needed to make varianted titles possible.

Example: http://www.isfdb.org/cgi-bin/pl.cgi?711971

--[[User:Stoecker|Stoecker]] 12:16, 24 April 2019 (EDT)

: I have experimented with the proposed change on the development server. Here is what the "Cover" lines on the two Publication pages look like after modifications:

:* '''Cover''': [http://www.isfdb.org/cgi-bin/title.cgi?999999999 ''The Languages of Pao''] by uncredited 
:* '''Cover''': [http://www.isfdb.org/cgi-bin/title.cgi?999999999 ''Sterne wie Staub''] by uncredited (variant of [http://www.isfdb.org/cgi-bin/title.cgi?999999999 ''The Languages of Pao''] 1974)

: It seems to look OK. As an aside, perhaps we should change "by uncredited" to "(uncredited)", but it would presumably need to affect all record types, not just covers, so we'd need a separate discussion.

: The next issue is performance since we would eventually end up with tens -- possibly hundreds -- of thousands of "uncredited" COVERART titles. As Dirk pointed out, we no longer display the Summary page for "uncredited", so that shouldn't be a problem. Also, at this point we have almost 57,000 "uncredited" titles, which doesn't seem to be causing problems. Adding another 100,000+ "uncredited" titles doesn't seem to be likely to cause additional performance issues.

: Are there other reasons not to enter uncredited cover art as "uncredited"? [[User:Ahasuerus|Ahasuerus]] 12:45, 25 April 2019 (EDT)

::I very much agree it's important and useful to be able to link appearances of artwork as variants.  But I am worried about using specifically "uncredited" to do it.  A legacy problem with cover art "credits" is that we don't follow normal publication data element rule of "as it appears in the publication".  We credit cover art directly if we are at all able to figure out who the artist is.  And in most cases where there is no credit but there is a signature, we normalize that to a canonical name and do not record the signature as the publication's "credit" (although we might mention it in the notes).  Given that practice, use of "uncredited" would lead to two inconsistencies:  Inconsistency among publication covers -- some where the cover art is not credited in any way would have an actual artist credit, while some would have "uncredited" -- and inconsistency between title records using "uncredited" -- some where it means only "there is no credit in the publication where this appeared" and some where it means "there is no credit in the publication where this appeared, and we have not as yet been able to determine an attribution; this may change in the future."

:: Also, one other scenario to think about:  If we have a tree of variants all for an uncredited piece of art, and for whatever reason we're suddenly able to determine the artist for the original/canonical appearance (easy example: say a later edition identifies the artist), now having anything in that variant tree using "uncredited" would essentially be a data error, as they should ALL be changed to reflect the newly-discovered credit.  Of course, we sort of want to ("would", really) do that now, even without the variant relationships.

::So I'd rather see something different used just for artists that reflects our artwork crediting practice.  For example, "undetermined".  Then we'd have three stock terms with well-defined and separate meanings:  "unknown" -- we do not know if a credit is present in the publication (could use this everywhere); "uncredited" -- no credit present in the publication, and we will not use any other source in its place; "undetermined" -- no credit in the publication, but we will use another source in its place if we can find one.  That would eliminate the inconsistencies.  And there could also be some smart processing to auto-replace any "undetermined" occurrences in the variant tree when a determination is made.  --[[User:MartyD|MartyD]] 21:22, 25 April 2019 (EDT)

:::Not sure if I understand you correctly, so I'd like to add my two cents. You rightly point out that we are handling art credits differently compared to other titles. Because we determine artist credits using multiple sources (as opposed to just recording what's on or in the pub), we can only ever have two objective states for them: they are either credited, or undetermined as of yet (you can also have "unknown" for pieces of art whose creator has been for sure lost to time, for example)
:::As you define uncredited I understand it's a (subjective) decision by an editor because who's to say someone else isn't determined to find the artist, so state should be "undetermined" as per your definition instead.
:::To summarize: for art we can only have credited, "undetermined", or "unknown" (the latter requiring an explanatory note as to why we'll never be able to determine the artist). Correct? [[User:MagicUnk|MagicUnk]] 02:38, 26 April 2019 (EDT)

::::That is pretty much what I was thinking, except we can have "unknown" when we do not have access to the book (or a suitable proxy for the physical book).  For example, if our data comes from an Amazon listing, and that provides a Look Inside that shows front and back cover and copyright page, "undetermined" would be appropriate -- we are reasonably certain it is not credited in the book, and we have not yet determined who the artist is.  If that listing did not provide Look Inside, but only the front cover (and no signature visible there), "unknown" would be appropriate.  Maybe that's too subtle, but I was thinking it's useful to understand the difference between the book didn't credit it and we don't know if the book credited it.  --[[User:MartyD|MartyD]] 06:42, 29 April 2019 (EDT)

::: Sounds fine to me. When talking about policies, this case here should also be discussed: http://www.isfdb.org/cgi-bin/title.cgi?2074927 The original is uncredited, the variant has a credit, but very likely it is simply wrong. --[[User:Stoecker|Stoecker]] 02:05, 26 April 2019 (EDT)

::::One other rather obvious scenario came up this weekend:  Two publications with identical, uncredited covers.  It would have been useful to show the sharing, and there was also some material about the possible artist that has no single home without a COVERART record to put it into -- the information would have had to have been duplicated in each pub record.  --[[User:MartyD|MartyD]] 06:42, 29 April 2019 (EDT)

:::::There is one other value to cover and one other 'state'. The value is blank, as so many are, and I'm not sure you've covered how you would deal with them - leave them blank (with what interpretations for searches and display) or default them. Which brings up another 'state' - covers for which an artist does not and cannot exist - such as pure text covers. For such covers, does the cover artist field get a special value, such as "none" or is it left blank, leaving it with unwashed masses? By the way, I'm all for being able to link uncredited covers and just want to be sure this doesn't muck things up. ../[[User:Holmesd|Doug H]] 08:15, 29 April 2019 (EDT)

::::::I don't propose to add unknown/uncredited/undetermined (whatever gets decided) to any pub/cover which is not required for linking (i.e used by another cover or interior art). In my eyes that would only add title entries without any real meaning. --[[User:Stoecker|Stoecker]] 17:28, 29 April 2019 (EDT)

:::::::I do think the possibility to link (within a given publication entry) to another publication with the same artwork is pretty much what is enough. The complications of using uncredited/undetermined/unknown for artwork in my eyes are not our first business (just my 5 cent of thoughts). [[User:Stonecreek|Stonecreek]] 01:50, 30 April 2019 (EDT)

::::::::We need to take care not to overthink this. Couldn't we suffice with only two states: either credited or 'unknown'? Credited would be the easy state to define: when we find the artist from whatever source, we credit the artist. 'Unknown' could then cover situations like

::::::::* We honestly don't know, and will never be able to find out who'd the artist been - for example because the artist is lost in time, or
::::::::* Not credited in the pub, and we can't find any secondary sources; which would cover 'uncredited'-as-not-in-the-pub and 'undetermined'-as-not-found-yet; both 'uncredited' and 'undetermined' can be considered substates of 'unknown' (as we're using any source -not just the pub- to determine the artist, uncredited doesn't really apply here)
::::::::Add to that that we would use 'unknown' only if we want to 'link' 2 or more records (the rest would remain blank), and we should be good to go. Thoughts? [[User:MagicUnk|MagicUnk]] 11:07, 30 April 2019 (EDT)

(unindent) A side question here because I think we are getting into the details before we had decided what exactly we are trying to do (or so it feels to me). Here is an easy example: [http://www.isfdb.org/cgi-bin/title.cgi?2486354 this set of books] will never have a coverart entry under the current rules (no artist; designer does not get). Are we trying to allow covers like that to get connected? If so, we are looking at adding a lot of additional coverart records... Or are we looking only at the case where there is an artist eventually? [[User:Anniemod|Annie]] 11:43, 30 April 2019 (EDT)
: No, I wouldn't think so. Adding a cover art record in this case wouldn't serve any purpose. Besides, the covers are already 'indirectly' linked via the common pub title, so no additional information would be conveyed with an additional art record. And I don't think we should add additional restrictions such as being eligible only when an artist could conceivably be identified. Using unknown coverart record when wanting to link should suffice I'd think. The rest can remain undetermined (left blank) [[User:MagicUnk|MagicUnk]] 02:09, 1 May 2019 (EDT)
:: Until a foreign publisher uses that artwork for another book - then you lose the connection from the book level. And if the idea is to connect this covers, where do we draw the line? [[User:Anniemod|Annie]] 02:54, 1 May 2019 (EDT)
::: Well, yes. If I understand correctly, this is exactly what Stoecker is asking for. [[User:MagicUnk|MagicUnk]] 17:04, 1 May 2019 (EDT)
:::: Which is what makes me stop for a second here. What happens if the work that contained the cover get deleted (it does happen). Do we remove the covers from all the parents now? And how do you explain to a new editor that they can add the covers only if there is a cover that does not show up on that screen. And if at the time we now have a cover we need to link, we have 20 books on that screen, do we edit all of them to import the original cover (and if not, how do we chose?) :) We will fill the DB with inconsistencies. Thus my question for a very easy usecase. So we either should just say that "(almost) every book (that has an image linked anyway) needs to have a COVERART" or we will be dealing with art elements for a very long time. And just because they will appear on the same page is not a good reason not to connect the coverarts to start with... 

:::: I would love to find a way to link those covers - I just want to keep the DB as consistent as possible while doing it. And there is a difference between "we do not have a coverart because we have no idea who the artist is" and "we do not have a coverart because there is no artist at all (it is a collage or a photograph or whatever). The request solves the first issue; my question is about the latter. Just thinking aloud :) [[User:Anniemod|Annie]] 18:04, 1 May 2019 (EDT)

:::::If we didn't have the legacy data and the very different standard used for cover artist credits to deal with, "uncredited" and "unknown" as they're used for other works would already address what we need.  So maybe the simplest thing is to change the policy to make those credits consistent with all other publication data (well, most other publication data): Exactly as it appears in the publication, using "uncredited" if no credit and "unknown" for when we don't have access to the publication and don't know.  An artwork-specific sub-policy would specify how to translate a signature into a credit when no other credit is present (following the review/interview model of avoiding creating new pseudonyms).  Blank would be allowed as an uncredited equivalent.  If we know a publication does not have a credit, and we determine the credit from some other source, then instead of inserting the credit directly, we'd require setting up of "uncredited" and then make that a variant of the credited record.  We'd just have to acknowledge that there's legacy data not conforming to that approach that would need to be fixed up over time.  Often, we'd be able to identify these situations from notes, but I don't think there would be any urgency to go clean them up.  And anyone needing a title record for linking or notes purposes could add "uncredited" as needed and variant to other "uncredited" instances.  Easy for me to say; I don't have to do the coding.  --[[User:MartyD|MartyD]] 19:26, 1 May 2019 (EDT)

Is there any conclusion? --[[User:Stoecker|Stoecker]] 08:33, 24 May 2019 (EDT)

: It was a good discussion which put a lot of options on the table, but I don't see a consensus. Sometimes it takes a few iterations until we find an approach that addresses all (or at least the majority of) the concerns and can be feasibly implemented. [[User:Ahasuerus|Ahasuerus]] 10:30, 24 May 2019 (EDT)

::It's too bad this died without solving [[User:Stoecker|Stoecker]]'s immediate problem.  Here's a limited proposal cobbled together from the things above:
::* Allow -- but do not require -- "uncredited" and "unknown" to be used for cover artist, the same way we use those credits elsewhere:
::** "uncredited" = no credit + no signature, and no attribution from another source.
::** "unknown" = we don't know if there's a credit (e.g., we have a listing from some secondary source that is silent on the credit)
::* Create a COVERART record using "uncredited" or "unknown" only for purposes of linking variant appearances of the artwork.  Otherwise, omit the COVERART record as is current practice when the artist cannot be determined.  We'd also tolerate this use in the absence of linking/variants (i.e., we would not consider such a credit in the absence of variants a data error).
::* Appearances of "uncredited" or "unknown" should be adjusted if more information becomes available.
::** Maybe "we" could make a clean-up report that finds sets of variant COVERART records where one or more variants uses "uncredited" or "unknown" and one or more others use something other than one of those.
::Is that something we could agree to?  Other than the candidate clean-up report, I think it's something that could be implemented only through policy, with no need for code changes.  The software's current handling should be adequate.  --[[User:MartyD|MartyD]] 07:43, 14 June 2019 (EDT)

::: That would be an enormous help. I have probably hundreds of cases now where the linking is done via the note field, which is error prone and you always have to check the same entries again and again to know if they are missing artists completely and searching original makes sense or if original is already known, but cannot be linked ATM. Maybe that isn't such a big issue in English world, but a lot of German books use uncredited artwork from earlier English books and and proper linking would make maintaining this a lot easier. --[[User:Stoecker|Stoecker]] 09:04, 15 June 2019 (EDT)

== Dates on COVERART variants ==

The [[Help:Screen:AddVariant]]'s '''Date''' bullet states that variant titles should be given the date of that variation's first appearance.  This applies whether the variant is due to differences in author credit or title wording, as well as to translations.  Handling of a recent submission to alter the date of a COVERART variant revealed that there is a practice of making some COVERART variants use the date of the artwork's first appearance, rather than the date of the first appearance of its variant use, at least in some cases.  As I understand it, the idea behind that practice is that unless the artwork itself is titled, there is nothing "variant" about art used for two different publications -- the difference is in the illustrated work's title, not in the artwork.

What do we think?  Should the current practice continue and be codified, or should that practice be altered to follow the broader variant dating scheme?  One practical problem I see with the current practice is that there would be an inconsistency among some COVERART variants, since presumably we would use different dates if the explicit artist credits were different (just as we would use different dates if an author credit were different).  I don't know if requiring more careful thought about what date to use is a good thing or a bad thing. :-)  --[[User:MartyD|MartyD]] 07:21, 14 June 2019 (EDT)

:More on the background: Most pieces of art in the database are - contrary to the first sight on a page of ISFDB - not titled at all. It is we who decided to give an illustrative work the title of the piece it is used as an illustration for. I see the immediate merit to give an illustration the title it is first used for: in many cases it was commissioned for that, and it is the most practible way for us to handle pieces of art. However, if it is re-used, there seems not to be much meaning in assigning a different date than that of first publication: the artwork is the same, and it is quite discussable if the 'title' should be altered or remain the initial one. The respective editor uses graphics from out of a pool available at that time and place. 
:Moreover, what is interesting about a piece of art in respect to its creator for me (and many others I'd think) is its title (mostly unknown to us), when it was created (also mostly unknown to us), and when it was first published (in most cases known). However, we have pieces that were not commissioned for a piece of speculative fiction, and I do advocate that they should bear their date of first publication or becoming publicly available (i. e. pieces of fine art), and it is because for reasons  of consistency that those pieces should be catalogued with their contemporary date. That are my thoughts on the matter, anyway. [[User:Stonecreek|Stonecreek]] 11:00, 14 June 2019 (EDT)
::I am not if favor of a differing standard for dating artwork.  As with other title types, having the date of an original publication on the canonical title makes sense and there is nothing to be gained by repeating that date whenever the artist credit or title under which the artwork appears changes.  The original publication date is still preserved just as it is with other title types.  Myself, I find it useful, or at least interesting to know when a piece of artwork was first published under a given title.  I'll also point out that not all titles are our invention, since variants can jump from COVERART to INTERIORART, sometimes the title is determined from the caption where the work is published.  My last reason for opposing a change to the existing standard is that multiple standards is more difficult to explain to new users and adds complexity to the rules with no real benefit.  --Ron ~ [[User:Rtrace|Rtrace]]<sup>[[User talk:Rtrace|Talk]]</sup> 18:50, 14 June 2019 (EDT)
:::I agree with Rtrace. ···[[User:Nihonjoe|<font color="darkgreen">日本穣</font>]] · <small>[[Special:Contributions/Nihonjoe|<font color="blue">投稿</font>]] · [[User talk:Nihonjoe|Talk to Nihonjoe]]</small> 20:03, 14 June 2019 (EDT)

:::: That pursue leads to the consequence that interior pieces like - for example - 'Amazing Stories, June 1926 (cover)' haven't got 1926-06-00 like they should (and anyone interested in art should expect) but the date of the publication they got included in. Anyone interested in the chronology of publications a piece of art was published in only has to look at the list. And, I repeat, the piece of art usually was not published under that title, it is only by '''our assignment''' that those titles are displayed in the list. [[User:Stonecreek|Stonecreek]] 01:11, 15 June 2019 (EDT)
:::: It also doesn't take into account the pieces that are in the database but weren't published initially on a speculative publication: classical / fine art, and works by 'speculative' artists but published for example with a crime fiction or a nonfiction item. We have loads of them from both fractions and it would be of interest when they were first published / publicly available. It would be most comforting to see in the title & in a given publication from what time they date. [[User:Stonecreek|Stonecreek]] 02:58, 15 June 2019 (EDT)

::::: I think, the points made by Ron and Christian are both valid. Using Christian's approach for cover art dates adds complexity to the rules and moderation, which I'd rather find undesirable, on the other hand it'd indeed be strange for casual user to see only the date 2002-10-00 for {{T|1334797|Amazing Stories, June 1926 (cover)}}, and not 1926-06-00. Moreover, in general it'd indeed be interesting to see classic artworks which have their own name listed with this name as the title (and their first date of publication). As for the latter, there are already data like this in the database, see {{T|2434949|this artwork by Vincent van Gogh}} or {{T|2448064|this by Hieronymus Bosch}}: the painting's title and publication date were used, if known, and the publications using it as cover art are variants of it, using the usual rule "date of variant = first apparance of the variant title".

::::: As a short-term improvement, what if the software also displays the date of the canonical title on a variant's title page if these dates are different? Not only for cover art, but for all title types. Example for "Amazing Stories, June 1926 (cover)" (see the red text):

::::: '''Variant Title of cover art for''': Amazing Stories, June 1926 <font color="red">• (1926) •</font> by Frank R. Paul

::::: That way the user can immediately see the original date (though in this special example the date is already contained in the title itself and therefore redundant). 

::::: To sum it up:
:::::* I'd rather keep the current rule regarding the date of variant covers as it is, but add the software improvement mentioned above.
:::::* We could add a rule which allow the creation of canonical titles like it was done in the Vincent van Gogh and Hieronymus Bosch examples mentioned above: "If the cover or interior art has been created and published before standalone (e.g. as a painting) and its original name is known, a canonical title for this art can be created, using the artwork's original name and date. If the original date is not known, enter 0000-00-00. All appearances of this art in publications are then variants of the original artwork's title record". This, however, also adds some complexity to the rules, but it's an new rule, not an exception from an existing rule and therefore easier to handle, I think... Jens [[User:Hitspacebar|Hitspacebar]] 05:44, 15 June 2019 (EDT)

:::::::I'm in agreement. For dates, artwork should follow the current rules. There is no reason to hide information (date first appeared under a variant/translation/type) & add rules complexity. For titles, artwork should also follow the current rules. If an artwork has an independent title (whether a classical or modern piece), it can be varianted to a new record with that name. This consistency would make for a better user experience. We already have enough exceptions that make it difficult for new users. As for the software suggestion, if a parent has a different date, the software will display that in the publication view when the publication has the variant. Seems reasonable to do the same thing at the title level. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 09:26, 15 June 2019 (EDT)

::::::::Sounds good to me: it's a compromise that I hope we all could live with (provided its possible to install). [[User:Stonecreek|Stonecreek]] 12:34, 15 June 2019 (EDT)

(unindent)  Here's proposed wording intended to cover the above discussion:

:''Title records for artwork (COVERART and INTERIORART) should follow the varianting and dating rules used for the titles of the works illustrated.  If the cover or interior illustration reproduces a piece of art that was originally produced as a standalone titled work -- e.g., such as one of Renoir's paintings or one of Ansel Adams' photographs -- a separate title record may be made to represent that original work and its creation date.  In such a case, use the COVERART or INTERIORART title type corresponding to the work's first known use for speculative fiction publication purposes.''

One gotcha that occurred to me is there is no generic "ARTWORK" title type, only COVERART and INTERIORART.  So I made up a recommendation for what to use.  Another thought I have is whether there should be a prohibition against making a separate title records for works commissioned for the SF publication where it first appeared.  The ISFDB is not an art database.  --[[User:MartyD|MartyD]] 10:47, 17 June 2019 (EDT)

: I was also thinking about the COVERART vs INTERIORART problem and had come to the same conclusion as you did. I'd make a few additions to your proposal which I think makes it a bit clearer (green text by me):
:: ''Title records for artwork (COVERART and INTERIORART) should follow the varianting and dating rules used for the titles of the works illustrated. If the cover or interior illustration reproduces a piece of art that was originally produced as a standalone titled work <font color="green"> under its own, original name</font> -- e.g., such as one of Renoir's paintings or one of Ansel Adams' photographs -- a separate title record may be made to represent that original work and its creation date.  In such a case, use <font color="green">the artwork's original name as title and</font> the COVERART or INTERIORART title type corresponding to the work's first known use for speculative fiction publication purposes. <font color="green">Example record: {{T|2434949|this artwork by Vincent van Gogh}}''</font>.
: As for your last two sentences: I don't understand what exactly you propose to be prohibited, because when a work was, as you wrote, "commissioned for the SF publication", then logically "it first appeared" in genre (because it was commissioned for it) and should, as usual, become the parent title. Either there's something missing there, or my Babelfish has hiccup :) Jens [[User:Hitspacebar|Hitspacebar]] 15:37, 17 June 2019 (EDT)

::What I mean is: We do not want someone to create a record for a Chris McGrath or Chris Moore (for example) painting just because it also exists as a separately titled work on one of their websites.  How we distinguish between the two different cases, I do not know. --[[User:MartyD|MartyD]] 22:01, 18 June 2019 (EDT)

(unindent) Too much travel lately so late to the party. I do not see why we should be treating art differently than the rest of our titles - threat the title as a "title, author, language" trio, date goes to when it was published for the first time in that combination (except when a parent needs to take a date from a child due to weird publishing order). Anything else both hides information that we have and makes it harder to use the DB to find anything (even if art does not change per language except for cartoons, hiding information deep into the lists when we have it is a bad DB design... and makes the DB less usable). Not to mention that it complicates things even more for new editors. 

Can someone point out one reason why are we trying to do something funny with dates here besides the "well, they are the same work" argument? We are not an art DB after all, we do not really look at copyright for anything, let's not go down into rules that will be hard to enforce (and research) just because... [[User:Anniemod|Annie]] 14:22, 19 June 2019 (EDT)

:The immediate problem I am trying to resolve is that I have an edit on hold that would change the date on  variant coverart record to the date of the parent. I would have rejected it, but upon investigating, I found there is a de facto practice, at least among some editors and moderators, of using a single original date for all variations.  So I need to accept or reject the edit.  If it should be accepted, the help ought to be changed to match.  If it should be rejected, we have a consistency problem.  My take is that the above discussion is trying to find a way to have the "standard" variant rules apply while also providing a way to capture and present a very different origination date. --[[User:MartyD|MartyD]] 20:52, 23 June 2019 (EDT)

:: A few thoughts now that I am feeling better and can do more than mindlessly process Fixer's data:

::* The proposed software improvement looks eminently reasonable and doable. {{FR|1285}} has been created.
::* Early on, the policy was that variant titles shouldn't have separate dates. It's possible that many variant COVERART titles that have the same date as their parent titles had been entered that way before the current data entry rules were adopted.
::* I believe I understand the distinction that Marty and Jens are trying to make in the second part of the proposed language. I appreciate the desire to capture it, but I am concerned that the proposed rule may add a certain amount of complexity and uncertainty.
:: My suggestion would be to:
::* Change the software as per {{FR|1285}}
::* Update Help to clarify that the current data entry rules for variants' date apply to art variants
::* Move the issue of non-genre art titles to a separate discussion

:: [[User:Ahasuerus|Ahasuerus]] 11:09, 24 June 2019 (EDT)

(unindent) {{FR|1285}} has been implemented -- see the "Variant Title of" line of [http://www.isfdb.org/cgi-bin/title.cgi?2153179 this VT page] for an example. At this time only the 4-digit year of the parent's date is displayed since that's what we do in the "Other Titles" section of Title pages. [[User:Ahasuerus|Ahasuerus]] 17:49, 24 June 2019 (EDT)

== Notifying the PV - rule update needed? ==

I'd like to get confirmation from the community whether the implicit rule of not having to (no longer have to) notify the PVer if a clear statement is added in the 'note to moderator' field can continue to be applied or not.

I've now had a price update rejected twice (which was clearly an error as I was the one who entered the wrong price in the first place, and which correction could be unambiguously confirmed to be correct by checking the online source to boot) with the rejection reason being that I didn't notify the PV first. This rejection is not justified imo because

1. I've done quite a few similar non-trivial updates before, where I provided a clear and unambiguous reason in the notes to moderator field, and that passed without any objections whatsoever; not from the approving moderator, and not from the PV, and

2. There have been previous discussions where the outcome pointed to no longer have to adhere to the 'notify the PV first' rule as long as a clear reason is provided, that being the current consensus, or so I thought

Formally documenting current practice in the rules has the benefit of clarity for any and all, and thus remove the inconsistent rules application within the moderators team of said rule.  Note that if an explanation is unclear or ambiguous, the moderators remain entitled to still reject these submissions of course. Thoughts on formalizing current practice? [[User:MagicUnk|MagicUnk]] 14:03, 3 September 2019 (EDT)

:This was for one of my verifications. I have corrected the price, and adapted the message on my talkpage (I don't want to be informed of changes like this). I'm in favor of changing the [http://www.isfdb.org/wiki/index.php/Reference:Primary rules], but not for every change. In the not too distant past we had a moderator who even deleted primary verified pubs without informing the verifier. There should be some value in (primary) verification. --[[User:Willem H.|Willem]] 15:13, 3 September 2019 (EDT)

:: It really comes down to who the PVs are. When I am approving, I do look at the page of the PV to see what notes they have on notifications. So the same non-trivial update may go through in one case and be held for notifications in another. Which may be a bit confusing for an editor but I do not think that we can change anything around that. 

:: Notifications are still expected for non-trivial edits where editors do not say outright not to notify them. The moderator note field is a great one but... think about some of the more prolific PVs. When I go on one of my cleaning frenzies, some of them can see hundreds of "changed PV" in their lists per day. 10 days vacation can make a mess of their lists (we do not have that many left but when I was doing LCCN and OCLC moves, the numbers were not exaggerated). A major update will get lost in the shuffle - so most people would expect that the non-trivial changes are communicated in other ways as well. The agreement we were veering towards was "do not notify if it is a trivial change" (and noone picked up the definition of trivial although it was tried), not "no need to notify ever" I think.

:: Prices are especially problematic when they are not physically printed on a book - list prices change and it gets... complicated. And different editors react differently when not notified. :) Outside of English, we rarely have too many editors working in a language - knowing their patterns and expectations helps. 

:: One small note - when adding an explanation, add also what changes to what so we have the old value saved in the notes. That makes it easier for everyone (because once approved, the old value is lost) :) [[User:Anniemod|Annie]] 13:56, 4 September 2019 (EDT)

::: An element to be covered if you want to formalize notification of PV, is to formalize how to annotate the source of information in an entry. When I PV an existing entry with no other PV, I generally leave in information I could not verify (e.g. Month of publication) and note the source as unknown. If people are adding or changing such information on an entry I've PV'd, as long as they note their source, I don't care. If they add a price based on catalogues or advertisements, I don't need to know - as long as they note the source so I don't get asked for information from my copy that isn't there. PV simply means I have a copy (for contact) and stand behind the information listed. If someone changes information after the fact, it makes me look like sloppy or stupid (I make enough mistakes and don't need help there). ../[[User:Holmesd|Doug H]] 10:34, 7 October 2019 (EDT)

::: As an aside, I'm not sure about timing of "notify the PV first". I generally submit my update and with the submission differences in front of me, create my notifications - so after submission but almost always before processing by a moderator. If I notify first, then create the update, I can't really see the difference (in the entry and the result). And if I'm supposed to wait for a response from the PV, I'll quickly lose track as my edit queue is usually books on the desk and there's not that much room left. ../[[User:Holmesd|Doug H]] 10:34, 7 October 2019 (EDT)

::::I think it's important to check with PVs before a destructive edit of information ostensibly from the publication (i.e., unless documented as coming from another source).  I also think it is important to notify a PV -- unless explicitly directed not to do so -- of additions that might indicate a different edition.  For example, adding to an existing set of contents, capturing a stated publication date or price or artist credit, etc.  We have seen on multiple occasions two otherwise identical-looking publications differing on some of those details.  To me, that is important enough to merit a talk page note, even though the PV could theoretically see via the notifications that the additions have been made.  I agree with the up-thread comment that there's too much noise for many PVs, and in this case we ought to be asking the PV to make an extra effort to confirm the presence of whatever was added in the PV's copy.  --[[User:MartyD|MartyD]] 10:22, 9 October 2019 (EDT)

::::: I agree - those are not minor changes - a cover that visually matches another copy and we have the artist from there is (although a check needs to be made if the other edition does not use the canonical - we may need to do it here), adding contents and/or date changes on verified books may mean a different edition. And describing what was changed -- once approved, the "old state" is lost so not being clear enough on the changes makes it hard to backtrack if needed. [[User:Anniemod|Annie]] 10:36, 9 October 2019 (EDT)

== Eligibility - need a second set of eyes.  ==

Our [http://www.isfdb.org/wiki/index.php/ISFDB:Policy#Included current policy] for web-only publications is:
* Speculative fiction webzines, which are defined as online periodicals with distinct issues (note: online periodicals without distinct issues are not considered webzines)
* Special speculative fiction issues of non-genre webzines
* One time speculative fiction anthologies published on the Web 
* Online publications available exclusively as a Web page, but only if:
** published by a market which makes the author eligible for SFWA membership (listed here), OR
** shortlisted for a major award 

And the excluded section is also specific:
* Works published in a web-based publication and available exclusively as a Web page -- such as blogs, author-run sites, fan fiction, web serials, etc -- unless listed in the Included section 

Under these rules, [http://www.fartherstars.com/ Farther Stars Than These] does not appear to be eligible (unless we want to stretch the "distinct issue" to mean "you publish something every Thu so we call that your distinct issue).  I do not see any major awards either (which is how we get Tor.com). We already have [http://www.isfdb.org/cgi-bin/pe.cgi?54108 some] and some more unconnected to the series approved... 

If we call these issues, it opens the door for any author basically publishing "my new poem every Friday on my site". I am ok with opening the rules a bit wider again but we need to figure out how. 

So as a start - can someone verify my reading of the rules and confirm that this one is indeed not eligible? Or any thoughts really. [[User:Anniemod|Annie]] 13:47, 3 October 2019 (EDT)

: I'd say you're right in the non-eligibility for this case. Consider one writes a poem or a short story on a house wall, which seems to be a quite similar case. We wouldn't want to index this here, I'd think. [[User:Stonecreek|Stonecreek]] 11:39, 7 October 2019 (EDT)

== How to use the translator template ==

I would like to hear some opinions on this subject. I've been adding the translator template to the Dutch titles, based on the rule "exactly as credited in the publication". That means some translators will be in the database under several pseudonyms (Annemarie Kindt / Annemarie van Ewijck / Annemarie Kindt-van Ewijck, A. van Ewyck etc). I also unmerged a number of translations (C. A. G. van den Broek was later known as Kees van den Broek for identical translations). Now one of the moderators has merged one of these again (see [http://www.isfdb.org/cgi-bin/title.cgi?1462240 here]). Have I been wrong in using the "exactly as credited" rule? --[[User:Willem H.|Willem]] 08:25, 7 October 2019 (EDT)
: Also interested, based on Jules Verne translations. With the plethora of reprints for Jules Verne, translators often are not credited, but the actual translation (and hence translator if known) can be identified based on the text. Different translations warrant different title records and the notes should include the translation template. At the publication level, the translator may be attributed differently or not at all, but it is still a publication of that title. My take is that publication records should note the translator as credited (or if uncredited). The title record should probably use the equivalent of a canonical name. Under this approach: should the translator template should be used in both title notes and pub notes? ../[[User:Holmesd|Doug H]] 10:12, 7 October 2019 (EDT)

::I'd advocate the approach of 'canonical name' (that's why I merged the two titles): the title / the translation is the same, and any change of name (because of a pseudonym, a marriage or anything else) can be easily recorded in the notes of the respective title.
::And for the second item: I do use the template in both: titles and publication. This way one can also determine the text more easily when looking at a publication entry (but it's not a top priority for me, only when entering or updating an existing entry I add this). Christian [[User:Stonecreek|Stonecreek]] 11:35, 7 October 2019 (EDT)
::: If we do “as credited” and we still do not have variants of variants, we will splinter our variants even more. Do we really want 6 titles of the same translation, author name and title name because the publishers decided to credit slightly differently or someone changed their name? While author names make sense being credited as per the title page  (they help identify the books), splitting the translators the same way will make it harder to find the books with your translation. And the publication can always have the record as wanted/needed A the translator on the title level is for identification. In multinamed translators, I would use aka or something similar if I know the information and note a text where it is different for example. Not to mention that the “credit the canonical if credit is from secondary” is not that easy when some of those translators don’t have canonical name yet. Just thinking aloud while boarding a plane here. :) [[User:Anniemod|Annie]] 11:53, 7 October 2019 (EDT)
[[User:Anniemod|Annie]] 11:53, 7 October 2019 (EDT)

::::Looks like there are no warm feelings for "exactly as credited". I'll just leave it at that. No hard feelings. --[[User:Willem H.|Willem]] 15:13, 10 October 2019 (EDT)
::::: To clarify my paragraph - I like "exactly as credited" on the publication. Titles should not be split into variants to support them, so a single canonical name for titles would result. Making that consistent across titles is another story. ../[[User:Holmesd|Doug H]] 15:23, 10 October 2019 (EDT)
:::::: Same here in case It was not clear. We will make them consistent when we migrate them basically - the we will figure out who is who and what is their canonical. We had always known that the migration will be fully automatic. One problem at a time. I managed to separate so many wrongly combined variants (the Italian titles were the main offender and the English ones still have a lot of these) that it is worth it even just for that. :) [[User:Anniemod|Annie]] 16:00, 10 October 2019 (EDT)
::::::: I think it makes sense to have the canonical translator name on title level, and any variant on pub level. The question is, what do we do '''now''' to ensure 'easy' migration once the necessary changes are made to accommodate translators, and to identify canonical and any variant names? Is it sufficient to enter a 'best guess' for the canonical on title level (using the template), and also always add the translator on pub level "exactly as credited" (also always unsing the template), and with clarifying info in the notes fields as needed? If so, can we bolster up this rules clarification somehow so that it will be ensured to be followed/enforced going forward? [[User:MagicUnk|MagicUnk]] 09:38, 11 October 2019 (EDT)

== Comics and Graphic novels and (insert whatever name they use in your language) ==

Technically these are never eligible:
"Speculative fiction is defined to exclude: Comic books, manga, and graphic novels " from [http://www.isfdb.org/wiki/index.php/ISFDB:Policy#Included The Policy].

However, we do make an exception for our authors when they are the author and it is part of their series - although we never updated the rules, this is the de-facto practice from what I had seen. 

So today while working on the Cleanup reports, I find [http://www.isfdb.org/cgi-bin/pl.cgi?699101 this]. After fixing it (it was added as a novel...), I kinda wondered why we have it at all. Gaiman is one of our authors but if we go down that road, we will get flooded with his comics (not that the 56 we have now are not enough of a flooding). And we also have a lot of [http://www.isfdb.org/cgi-bin/ea.cgi?1922 Alan Moore]'s which makes even less sense.  So I would like to start a conversation on the rules on two separate topics:
* Do we want to formalize what is actually accepted (and should we really accept these)? Or actually start enforcing our own rules? 
* Is anyone opposed to me starting a cleanup campaign on what we have and should not be here - I will post over in Community before deleting but having these in the DB misleads our new editors. As of this writing we have [http://www.isfdb.org/cgi-bin/adv_search_results.cgi?USE_1=title_graphic&O_1=exact&TERM_1=Yes&C=AND&USE_2=title_title&O_2=exact&TERM_2=&USE_3=title_title&O_3=exact&TERM_3=&USE_4=title_title&O_4=exact&TERM_4=&USE_5=title_title&O_5=exact&TERM_5=&USE_6=title_title&O_6=exact&TERM_6=&ORDERBY=title_title&ACTION=query&START=0&TYPE=Title 558 titles] with the graphic flag added to them. Some are probably legitimate entries we want. Most need to go under the current rules (even if extended to known authors in known universes...).

So... any thoughts? [[User:Anniemod|Annie]] 00:57, 10 October 2019 (EDT)

:* I'd say we are already struggling with the task we have chosen to care for: to bibliograph '''speculative fiction'''. So, comics and graphic novels are out, and should principally stay this way. Thus, I'd advocate the planned clean-up. Christian [[User:Stonecreek|Stonecreek]] 04:59, 10 October 2019 (EDT)

:* Is there an equivalent to ISFDB for graphic material? If so, might it make sense to utilise, reference and/or co-operate with them in some way? ../[[User:Holmesd|Doug H]] 08:20, 10 October 2019 (EDT)

:: Depends on what you are looking for. [http://comicbookdb.com/ Comic Books DB] is good and I tend to hit them first when I am looking for something comics related. [http://comicbookdb.com/issue.php?ID=25259 This] is their record on the Black Orchid I linked above from our site.

:: [https://www.comics.org/ Grand Comics Database (GCD)] is the other good option out there. Their [https://www.comics.org/issue/335429/ Black Orchid] is the page for that. 

:: Both are way better than us in indexing comics... [[User:Anniemod|Annie]] 09:38, 10 October 2019 (EDT)

::: I was thinking that the author pages should include a link to the graphic site's author page, and that we use their tracking of material as a criteria for filtering out graphical material.  ../[[User:Holmesd|Doug H]] 11:34, 10 October 2019 (EDT)

:::: I would not be opposed to it at all :) [[User:Anniemod|Annie]] 11:48, 10 October 2019 (EDT)

:* I'd suggest comics/graphic novels/etc... are out '''unless''' they have also been published as regular title (ie without the pretty drawings :)), then they are an acceptable variant and can be included. [[User:MagicUnk|MagicUnk]] 11:21, 10 October 2019 (EDT)
:: Well... if we open the door for "graphic adaptations", then this will allow A LOT. Almost none of the comics have the complete stories. So we need to be careful. If it is indeed the complete story, then yes - these are in - they are just heavily illustrated books...). [[User:Anniemod|Annie]] 11:48, 10 October 2019 (EDT)

::: We do have the 'included' rule #4 (Works (both fiction and non-fiction) which are not related to speculative fiction, but were produced by authors who have otherwise published works either of or about speculative fiction over a certain threshold). I.m.o. that means if we enforce the rules, Neil Gaiman's comics are in, but Alan Moore's are out. I recall an earlier discussion about adaptations (only in when the adaptation is done by the author himself). On the list above: I think it's a good start to review those titles, but it's far from complete. The title flags are a relatively recent addition, and most of the graphic stuff in the database will not have the flag set yet (see [http://www.isfdb.org/cgi-bin/pl.cgi?41942 The Illustrated Harlan Ellison] for example). I think the rules as we have them are adequate. --[[User:Willem H.|Willem]] 13:49, 10 October 2019 (EDT)

:::: Well, that's why I wanted a discussion - I will give you Gaiman if you insist... I do not think that we should go for the graphic contents even for our authors but sure - we will leave it (although if the editor that added it cannot be bothered to even set the format, I am not sure why they added it...). On the other hand, how extensive do we want to allow it? Gaiman is prolific - he has hundreds of stories in graphic anthologies and single issues - and with the rules now allowing non-ISBN books, technically these are fair game... and I really do not think we should go there. So where do we draw the line? :) [[User:Anniemod|Annie]] 14:05, 10 October 2019 (EDT)

:::: PS: and yeah, I know this is the tip of the iceberg as far as titles are concerned. But it is a start. [[User:Anniemod|Annie]] 14:38, 10 October 2019 (EDT)

::::: Would Gaiman be any worse than Asimov? B.t.w. I would support a rule change to rule out single issues (these were never accepted as far as I know). And I like the idea of linking authors to their graphic site's author pages. --[[User:Willem H.|Willem]] 15:05, 10 October 2019 (EDT)
:::::: No but under the current rules they are kinda in a gray area. When the rules were written, we had a lot more restrictions on what was acceptable. We had been expanding the scope - we just need to tighten it a bit for that if we let our authors in based on the “above threshold” rule. [[User:Anniemod|Annie]] 16:04, 10 October 2019 (EDT)
::::::: What was the original reason to add a graphics flag? And if we don't want to allow graphic novel adaptation of pre-existing work, what's the use of that flag anyway? Just thinking ...[[User:MagicUnk|MagicUnk]] 09:26, 11 October 2019 (EDT)

:::::::: At the time the decision was made, we already had a bunch of graphic novels on file, but there was no visual way to distinguish them from regular fiction. It could get particularly problematic when we had a regular prose version and a graphic version of the same story. The "graphic flag" was our way of saying "at the very least we are going to make it very clear what these titles are". Its addition wasn't supposed to change the scope of the project, only clarify what we had. [[User:Ahasuerus|Ahasuerus]] 10:05, 11 October 2019 (EDT)
::::::::: If I understand well, the problem at the time was that there were graphic publications already in the database. Rather than removing the offending records (assuming no graphic contents was allowed at the time), a solution was put in place to flag the records as graphic. This seems to me as a solution put in place because there was (is?) reluctance to delete records that did (do?) not comply with the DB's scope (because not to want to offend/chase away the editor that added them ?), resulting in the situation we're in today. So, rather than try to come up with solutions that are suboptimal, why not remove ALL graphics publication records altogether (assuming we're not really interested in graphic pubs - even where they are graphic adaptations of previous published material)? This at least has the advantage of clarity: 'if it's graphic, it isn't entered in the DB'. Period. :)
::::::::: Of course if we -do- want graphics contents, that's another matter altogether ... So, should we vote to keep graphics contents? And if so, what would be the criteria? Only graphic variant of pre-existing pubs?, graphics pubs of 'our' authors, other...? I'd vote to remove ALL graphics contents, and adjust the rules accordingly. [[User:MagicUnk|MagicUnk]] 11:45, 11 October 2019 (EDT)
:I see no problem with including graphic novels (not comic books, but graphic novels) if the author or artist is "above the threshold", or if the work is part of a series that is mostly prose, but includes some graphic novel works (such as the "[http://www.isfdb.org/cgi-bin/pe.cgi?42559 White Sand]" series from Brandon Sanderson, which is part of his Cosmere series, or the "[http://www.isfdb.org/cgi-bin/title.cgi?1000069 Veiled Alliances]" graphic novel by Kevin J. Anderson, which is a part of his [http://www.isfdb.org/cgi-bin/pe.cgi?11676 Saga of Seven Suns] series, and has also been released as a [http://www.isfdb.org/cgi-bin/title.cgi?2616034 prose novel]). If neither of those exceptions apply, then they shouldn't be included. ···[[User:Nihonjoe|<font color="darkgreen">日本穣</font>]] · <small>[[Special:Contributions/Nihonjoe|<font color="blue">投稿</font>]] · [[User talk:Nihonjoe|Talk to Nihonjoe]]</small> 14:49, 11 October 2019 (EDT)

:: I do not mind these either. But the rules do not make that distinction thus the opened discussion. And the line between graphic novels and comics in the US industry had blurred a lot - a lot of what are essentially graphic novels get chopped into installments and get issued as floppies first - as limited series (including some of the GNs in the long running prose series) in an attempt to make some more money. So making that distinction is not as easy as it used to be. [[User:Anniemod|Annie]] 14:56, 11 October 2019 (EDT)
:::For your example, I would include the graphic novels and not include the individual comic book issues. A note could be made indicating the graphic novels were first published as serialized comic books, and we could determine how we want to list the date (since the comic books would have been published first. I suggest going with the date of the graphic novel publication (to make things simpler on our end) and leaving a note stating when the comic book issues were published (if known). ···[[User:Nihonjoe|<font color="darkgreen">日本穣</font>]] · <small>[[Special:Contributions/Nihonjoe|<font color="blue">投稿</font>]] · [[User talk:Nihonjoe|Talk to Nihonjoe]]</small> 15:25, 11 October 2019 (EDT)
:::: Technically these are not graphic novels if they were serialized, they are collected limited series. But it is a distinction without a difference these days. :) I would agree on that - we treat them as books and get their date from when the book was published first and  we should never list any single issues of comics. I think we should be even more restrictive than that but that will at least close that loophole. I will think on a language to propose that covers what we are talking about. And the no-floppies should have higher priority than the threshold rule I would think. [[User:Anniemod|Annie]] 16:01, 11 October 2019 (EDT)
::::: Sorry I missed this discussion.  We discussed this last [http://www.isfdb.org/wiki/index.php/Rules_and_standards_discussions/Archive/Archive16#Graphic_Novel_status.3F here] and [http://www.isfdb.org/wiki/index.php/Rules_and_standards_discussions/Archive/Archive14#Graphic_novels here] most recently.  I thought we were okay with 1) no comic books (i.e. periodicals) and 2) authors above the threshold.  That would seem to provide a reasonable guideline. [[User:Taweiss|TAWeiss]] 22:42, 16 November 2019 (EST)

:::::: Yup. Which is why I posted before I started cleaning - I was sure some of what I was seeing was legitimate (the threshold rule...- my brain was not connecting the dots properly...) :) [[User:Anniemod|Annie]] 23:00, 16 November 2019 (EST)

::::::: One more thing to think of: Authors like Harlan Ellison or Ron Goulart should be over our threshold, but they also did some work in the comics field (for example Ellison did an 'Avengers' story, if I remember right). Once we have this or similar installations in other series, there certainly will be the attempt to enter more (if not all) of the particular series. [[User:Stonecreek|Stonecreek]] 01:03, 17 November 2019 (EST)
:::::::: And with Marvel and DC reprinting everything (multiple times), those stories will show up. I have a similar problem with mystery series from non-over threshold authors that have 1 book that is ours (because then we enter only that one and explanations but people have a natural inclination to finish series) or explaining why one of the Agatha winners is in and the rest are not (based on who wrote them). The whole over the threshold rule makes some sense in some ways but it also opens the door for awkward questions. As much as I like comics, I do not think we should have opened the door even for our authors and series. But... :) [[User:Anniemod|Annie]] 01:11, 17 November 2019 (EST)

== "Title Length" field ==

[[Template:TitleFields:Length]] currently reads:

* '''Length''' - This field is only used for SHORTFICTION titles. It indicates the number of words in this SHORTFICTION title. Note that if you are cloning a publication, this field is not editable for existing content records.

The allowed values are:
* ''shortstory'' - A work whose length is less than or equal to 7,500 words. (Roughly 20 or fewer pages in a book.)
* ''novelette'' - A work whose length is greater than 7,500 words and less than or equal to 17,500 words. (Roughly 20 to 50 pages in a book.)
* ''novella'' - A work whose length is greater than 17,500 words and less than or equal to 40,000 words. (Roughly 50 to 100 pages in a book.)

As we have repeatedly discussed on this page and elsewhere over the last few years, the "rough" page count guidelines may have been a decent rule of thumb in the past, back when we mostly dealt with US/UK books published by traditional publishers. However, they have become increasingly less reliable lately because different publishers use different fonts, different page layouts, etc.

As I mentioned on the Help Desk page the other day, the easiest way to deal with this problem may be to delete these guidelines from the template. Instead we could add a link to a new Wiki sub-page with a more detailed explanation of how to count words in a story/book, how publishing practices have evolved, etc.

What do you think? [[User:Ahasuerus|Ahasuerus]] 12:32, 3 November 2019 (EST)

: Reasonable approach. Can you confirm two statements: A SHORTFICTION can have its length changed at the title level and it will ripple back to the container objects which hold them; You can't change a SHORTFICTION (novella) to a NOVEL and vice versa. Just trying to confirm that not all boundaries are equal when it comes to the Wiki sub-page explanation. ../[[User:Holmesd|Doug H]] 16:21, 3 November 2019 (EST)

:: You can change it in both cases but a change in the length does not require changes in the containers - it is still a short fiction. Changing from SF to novel and vice versa requires more steps as the containers need changes as well. Is that what you were asking? [[User:Anniemod|Annie]] 23:31, 3 November 2019 (EST)
::: Trying to point out that getting the length wrong when entering a new publication/title has different ramifications at the 40,000 (word) level. ../[[User:Holmesd|Doug H]] 23:50, 3 November 2019 (EST)
:::: Except that you used to word "can't" making the statement you wanted to be confirmed incorrect - you need a qualifier there :) You can, just not as easily. Still, short of literally counting every word, we will need to convert occasionally (probably more and more often with the way printing is these days). So while not a trivial change, it is still faster than adding the work from scratch. :) [[User:Anniemod|Annie]] 00:00, 4 November 2019 (EST)

: I'd think this change would be all for the good. [[User:Stonecreek|Stonecreek]] 02:30, 4 November 2019 (EST)

=== "Title Length" field - Outcome ===

As per the outcome of the discussion above, [[Help:How to Count Words in Prose Fiction Titles]] has been created. [[Template:TitleFields:Length]] has been updated to link to the new Help page. Hopefully the wording makes sense. Anything else that the new page should say? [[User:Ahasuerus|Ahasuerus]] 18:34, 29 November 2019 (EST)

== The covers again - languages and dates ==

We seem to have two competing practices around covers:
* Hide the data from anyone that actually is interested in it by
** merging covers with different languages which happen to share a name
** dating  a cover variant to the first appearance under any name, any language
* Keep the data visible and searchable by
** varianting same-named covers from different languages 
** leaving the date to show the first usage in that language under that name/author name. 
The first of those practices leads to inability to find if a cover is used in a language (short of opening every publication) or when it was used first in a language. Removing that data from the DB and making it impossible to find (unless you are really determined) is just a bad DB practice (and devalues our records). If we want to show the data differently (so we can show the data as it is being forced by now from the first type of edits), we can do it on the front end - I understand that it is the same piece of art but that does not mean that we should not be saving the data we have about its usage and allow people to search it...

So can we please agree on what we actually should be doing and then all of us follow the same practice? As the rules are written now, option 2 is what should be happening - as it happens for text pieces. I personally prefer (and use) the second practice - I would rather have the data than not.

Thoughts? Opinions? [[User:Anniemod|Annie]] 15:41, 7 November 2019 (EST)

:I thought we had agreed to treat art variants the same as other variants, meaning the variant gets the date of it's first publication as that variant. I'm all in favor of practice #2. Perhaps we should even have a cleanup report (variants with the same date as the canonical title). For now, when I see one, I correct it. --[[User:Willem H.|Willem]] 16:41, 7 November 2019 (EST)

:: That's my recollection as well (and it is [http://www.isfdb.org/wiki/index.php/Rules_and_standards_discussions#Dates_on_COVERART_variants just a few items above]) - no special rules for art. And yet, varianted covers keep getting their dates reset - sometimes multiple times after I stumble on them and fix them. 
:: And the cross-language merging should be a no-brainier either. We even have "Multi-language pubs" report to catch exactly these issues - but the pubs just get ignored from there and we are back to square one. [[User:Anniemod|Annie]] 16:54, 7 November 2019 (EST)

::: That's bad. Can you see who does this? Or, do you have a recent example? --[[User:Willem H.|Willem]] 17:00, 7 November 2019 (EST)

:::: On the repetition - not off the top of my head - I just remember fixing records I had fixed before and I see the entries being ignored by someone in the report before I manage to split - sometimes while I have the screen open for splitting. 
:::: On the recent: look in the recent approvals for one of the latest ones (between 3 and 4:30 pm server time today). "Die Gabe des Imperators" is a recent example for the date change issue; "Xenos" for the cross-language merge. It kinda made me finally post about it. We need to figure out what we are doing or we have moderators cross-editing on top of each other and confusing the editors (new and old). Plus an inconsistent, partially unsearchable dataset. 
:::: I am pretty sure that we have a few different moderators doing something similar, Stonecreek is just one of the most active in working the queue so most visible for that. And we did have a discussion [http://www.isfdb.org/wiki/index.php/User_talk:Stonecreek#Le_secret_des_initi.C3.A9s_cover_art back in January on dates] - we really should fix the labels (but that is besides the point). I can see his arguments on visualization but crippling the DB is not the way to solve it. Unless we collectively decide to do that (which I hope we won't but majority rules). [[User:Anniemod|Annie]] 17:19, 7 November 2019 (EST)

::::: I thought so. Let's see what other editors/moderators have to say. --[[User:Willem H.|Willem]] 17:25, 7 November 2019 (EST)

::::::I'm pretty sure I've only ever done varianting (using "check for duplicates" or "make this a variant" links). I wasn't aware of any merging being done. ···[[User:Nihonjoe|<font color="darkgreen">日本穣</font>]] · <small>[[Special:Contributions/Nihonjoe|<font color="blue">投稿</font>]] · [[User talk:Nihonjoe|Talk to Nihonjoe]]</small> 18:12, 7 November 2019 (EST)

::::::: You merge when you select two entries in the "check for duplicates" screen (or did you mean something else). Different languages won't show as duplicates though - so it is not happening because they show up there. And it mostly happens for languages that use the same alphabet - so a title can be the same. For example [http://www.isfdb.org/cgi-bin/title.cgi?1445733 2312]. This English COVERART record has German and Spanish books attached to it. No way to find out that Benshoff's cover is used outside of the English world unless you open every publication... you cannot even use Advanced search because there is no cover in Spanish or German to find. [[User:Anniemod|Annie]] 18:20, 7 November 2019 (EST)
::::::::I guess, now that I think about it, I only really do "make this a variant" for covers, and usually only when I'm doing multiple submissions for a book that uses the same cover on many publications. ···[[User:Nihonjoe|<font color="darkgreen">日本穣</font>]] · <small>[[Special:Contributions/Nihonjoe|<font color="blue">投稿</font>]] · [[User talk:Nihonjoe|Talk to Nihonjoe]]</small> 19:50, 7 November 2019 (EST)

::::::::: I merge (and import) covers often but only when they are the same language (and artist and title and artwork) - the ebook, hc and tp of the same book for example. But depending on what you work on, how often that is needed varies. :) [[User:Anniemod|Annie]] 19:59, 7 November 2019 (EST)

:We already agreed upon the practice back in June (as <s>Willem</s>Annie linked to). That discussion had a pretty decent participation (at least by ISFDB standards) and it confirmed that cover art is supposed to be treated per the existing rules. There was no agreement to change the rules so all editors (especially moderators) should be following them. If it was solely up to me, there are things I would do differently. But it's not solely up to any of us, it's a community project and that means we all need to abide by the community consensus. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 17:11, 8 November 2019 (EST)
:: Yeah, well... apparently not everyone does agree or abide by it. Thus the need to reiterate more than once. And I forgot where the old discussion was (so added the link after it almost hit me on the nose when I opened the page later)...
:: Any opinion on the cross-language merging of covers? [[User:Anniemod|Annie]] 17:38, 8 November 2019 (EST)
:::That was touched upon in the prior discussion as well. Multiple people said there should not be special rules of artwork. That would apply to titles & languages as well. Sorry, misread the indent on the link. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 17:56, 8 November 2019 (EST)
:::: After checking that whole old discussion - yeah, of course we did. Even if it started only as a conversation about dates, the rules were for everything. Thanks for pointing that out! :) [[User:Anniemod|Annie]] 18:30, 8 November 2019 (EST)
::::: I'll ask Christian to stop changing these dates. Moderator qualifications specifically state 'A moderator must be someone who is willing to work to improve the ISFDB, and comply with the consensus gained on the ISFDB Wiki on the resolution of various bibliographic debates.' --[[User:Willem H.|Willem]] 16:23, 9 November 2019 (EST)

== pb and European books ==

Our current [http://www.isfdb.org/wiki/index.php?title=Template:PublicationFields:Format help page] for pb states: 
*For books as tall as 7.25" (19 cm) or as wide/deep as 4.5" (11.5 cm) use "tp".
Which effectively makes most of the European pocket editions "tp". The German "small format" has a width of ~12.5 cm; the Bulgarian (and most Eastern European) one after standard trimming is 12.0x16.5 cm(12.5 cm sometimes because of trimming and what's not) - which is normal - we all start folding from the same (different from the US) size and ratio.  

Do we have an informal agreement that these should be "pb" somewhere? If so, should we add to the help page something like 
* For European and other non-US/Canadian books, use tp only if the width exceeds 12.5 cm while the height is still less that 19 cm. 
If we do not have one, should we? I think that this will allow us not to need to dump all non-US books into "tp" without changing what "pb" means for the market it was created for. 

It is a separate conversation if we want 7.5"x4.25" (aka the new tall mass market paperbacks) to also fit under pb where they belong logically but one at a time. :)

Thoughts? Opinions? [[User:Anniemod|Annie]] 18:51, 10 November 2019 (EST)

: I do think that we already have a mutual agreement, at least for the German market [http://www.isfdb.org/wiki/index.php/Rules_and_standards_discussions/Archive/Archive15#Format_pb_vs._tp here]. Since Wolfram wrote that he would support this, I don't know why there had to be a disagreement again.
: In any case I still adhere to the conclusion reached there (and would support an extension to the European continental markets). To copy the passage:
::: 1) 'For books at least as tall as 19.01 cm (7.25") and at least as wide / deep as 11.5 cm (4.5") use "tp" '. 
::: 2) 'For books as tall as 19 cm  generally "pb" should be used'. except:
::: 2a) 'For books as tall as 19 cm, but with a width equal or higher than the height "tp" should be used'. Christian [[User:Stonecreek|Stonecreek]] 23:39, 10 November 2019 (EST)
:: I remember that discussion - I am not sure why the rules were never adjusted after it was concluded. I am ok extending the rules for the European market (well, all mm-as-opposed-to-inches based markets really) as described in your message (it will catch even more small-ish books than mine does) - but even if that is only for the German one, we need an update of the help page. Let's give everyone some time to see this and respond and then the help page will need to be updated a bit either for German only or for all mm-based countries. [[User:Anniemod|Annie]] 23:48, 10 November 2019 (EST)

::: Just want to point out that Canada is metric, but we use Imperial (US) physical sizes. So studs are laid with 40.64 cm (16 inch) centers. We'd likely use the US units. So wording on "all mm-based countries" may want some tweaking. ../[[User:Holmesd|Doug H]] 16:54, 17 November 2019 (EST)
:::: Good point. If I remember correctly, the US sizing for paper (and from there the size of books) is used in USA, Canada and parts of Mexico. I was trying to throw a bigger net than "continental Europe". Maybe "paper based on the metric paper formats"?  [[User:Anniemod|Annie]] 17:06, 17 November 2019 (EST)

:::I'm OK with this too. Many French pubs that were slightly on the wrong side of the pb / tp limit have been treated ''de facto'', for coherence's sake, as pbs by Hauck and then by me (considering the variations and evolutions of certain pub series), and this proposed change would help clarify matters. [[User:Linguist|Linguist]] 05:37, 13 November 2019 (EST).
:::::Again, 7.25" = 184.15 mm and 4.5" = 114.3 mm or am I wrong? Please correct this.--[[User:Wolfram.winkler|Wolfram.winkler]] 04:35, 15 November 2019 (EST)
:::::: Wolfram, this is what this thread is about - to agree what we are doing for European books. Do you support the current rule (US based sizing) or the expansion for European books as described above by Stonecreek - in mm and cm as well so noone needs to convert all the time? If your problem is the exact conversion - there is the word approximately there... [[User:Anniemod|Annie]] 23:04, 16 November 2019 (EST)

(unindent): Sigh. This topic has not only been discussed several times without an outcome, petering out again and again, but I also once got a request to compile a wiki page with all information about the problem and a list of (at that time) possible solutions, which I did. It got largely ignored. Here it is again: [[Softcover_publication_formats_on_international_markets]]. Maybe it helps to finally find a solution. The only solution for me is to get rid of "pb" and "tp", at least for other markets than English ones, and add "sc" for "softcover". Ahasuerus added the "Background" chapter back then, and especially his statement that "our "pb" and "tp" are '''uniquely ISFDB designations which do not map neatly onto current publishing practices in the US or anywhere else'''" was the final nail in the coffin for pb and tp for me. Why keep such a designation at all? I don't see any sense in it any more. Jens [[User:Hitspacebar|Hitspacebar]] 16:21, 17 November 2019 (EST)

: Me either. Although the US editors seem to like it. I'd say "merge them", add a free text "format" field (so we can record exact size or exact format name valid for the market the book is from" and stop trying to fit squares (cm based formats and ratios) into circles(rules based on inch-based formats and ratios). But if we keep it, it needs to be consistently applied so a new editor knows what to do and does not get told "you read the help page and followed it but this is not what we do". Which is what happens now if they are working on German books and the consensus above is followed by the moderator handling. Thus the thread. Again. :) [[User:Anniemod|Annie]] 16:41, 17 November 2019 (EST)

:: Keeping it and adding a rather general rule like the proposed one for European sizes above will only add another more or less arbitrary rule, but it will not solve the problem. The new rule would not fit the real world, and it will lead to questions later on which will be similar to the ones we are now dealing with. See the [[Softcover_publication_formats_on_international_markets#An_example|example for the German market]] on the wiki page: the "official" formats there are only partly size-based. The question by editors that will come up one day: "why do I have to use 19cm as the boundary between tp and pb if it has to be 20.5cm in Germany and a tp also must have inner front and back flips?"
:: Adding the just mentioned "official" definition as a new rule especially for the German market is no solution as well, because then several other rules for other markets have to be added, and it will lead to the disadvantages mentioned in "[[Softcover_publication_formats_on_international_markets#Possible_solutions|Add new formats for other markets]]
:: Jens [[User:Hitspacebar|Hitspacebar]] 18:20, 17 November 2019 (EST)

::: I am not disagreeing with you at all. According to a moderator, the German rule is in effect for German books and he had been changing and approving based on that - after we had a bit of a conversation when he changed a legitimate tp to a pb after I had confirmed with the editor that it is indeed too big to fit the sizing. According to that statement, I posted here in an attempt to find out where this understanding is coming from and what we need to do next. I am all for just dropping the distinction and be done with it. But I am not sure we have the support for it - thus trying to find a middle ground. If the middle ground is "nothing changes", then we have a big cleanup to do in some German publishers... If there is enough support to merge, all the better. The free text format field will allow us to save someewhere the "pb" for the old US/CA paperbacks and at the same time give us a place where we can specify formats that make sense to the markets (A format for UK for example; A5 for European, the size/ratio formats of Eastern Europe and so on - stuff that now goes into the notes). I can even live without it as long as we preserve the "pb" designation in a note (because people spent time collecting that data and I hate losing data). [[User:Anniemod|Annie]] 18:31, 17 November 2019 (EST)

:::: Yes, we are in agreement. I had already understood you point but wanted to add some flesh to the "But if we keep it" part because it looks like the discussion is mostly about correct numbers again instead of being about the more general question if we need the pb/tp distinction at all :) Preserving the "pb" and "tp" designation in a note is certainly a good idea if we decide to remove these formats from the list. Jens [[User:Hitspacebar|Hitspacebar]] 04:10, 18 November 2019 (EST)

::::: I'm against dropping the difference between PB and TB. these are totally different ways of publishing a book, and not only in the US. But I'm also against defining the format accurate to the millimeter. In almost any case, the intention of the publisher to publish either a paperback or a trade paperback is totally clear, and should i.m.o. be leading. That means the maximum or mimimum size should be no more than an indication of the format. --[[User:Willem H.|Willem]] 08:06, 18 November 2019 (EST)
::::::: That’s not how the rules are written now. Under the current rules, all the small European formats are about a cm too wide to be pb. Thus the whole repeated conversation. If the intention is different, we need to adjust the language in the rules. Otherwise we are making a mess and a user of the DB will need a PhD and a crystal ball to figure out of this pb is really small enough to fit on a shelf of mass market paperbacks or an exception based on an arcane non-documented sub-rule agreed on somewhere. :) [[User:Anniemod|Annie]] 10:28, 18 November 2019 (EST)

:Perhaps we can add a field or two to capture the height and width of books? Having that information might help alleviate any confusion. Someone also suggested somewhere (I can't seem to find it right now) creating a few new options in the format drop-down to cover North America sizing names, European sizing names, Japanese sizing names, etc. Just to throw a curveball, in Japan they have a format that's basically a soft hardcover: it's cover is thinner than a hardcover and is slightly flexible (though not as much as a paperback). I've been recording them as hardcovers here. ···[[User:Nihonjoe|<font color="darkgreen">日本穣</font>]] · <small>[[Special:Contributions/Nihonjoe|<font color="blue">投稿</font>]] · [[User talk:Nihonjoe|Talk to Nihonjoe]]</small> 01:57, 19 November 2019 (EST)

:: I am adding the exact size (and format designation) into every Russian, Bulgarian or other Eastern European book as a note. It can be useful and if we ever add the fields, it will be there to be moved. For covers like these, I would be adding a note as well so it is clear what they are (although if all Japanese books consider that a hardcover, no point adding the note). [[User:Anniemod|Annie]] 20:20, 19 November 2019 (EST)

::@ Annie, 184.15 mm and 190 mm is approximately equal? I can not believe it.--[[User:Wolfram.winkler|Wolfram.winkler]] 03:46, 19 November 2019 (EST)
::: Nope. We need to add some language around that, I agree. Let's first figure out what we do with the formats - it may turn out that it is not needed to have the conversion if we have separate rules. One step at a time. [[User:Anniemod|Annie]] 20:20, 19 November 2019 (EST)
::::Start a further discussion without result. That is the right way, indeed.--[[User:Wolfram.winkler|Wolfram.winkler]] 15:55, 24 November 2019 (EST)
:::::Always positive and inspiring. That's the way Wolfram! --[[User:Willem H.|Willem]] 15:57, 24 November 2019 (EST)
::::::I prefer an old proposal: Once again an old suggestion is the distinctive feature softcover/hardcover and in the second step the dimensions length/width/thickness. With these data a format of a written book ist exactly described and everyone should be able to fill the database with these data. --[[User:Wolfram.winkler|Wolfram.winkler]] 03:47, 26 November 2019 (EST)
::::::: Which will require a software change while changing the policy will require just a Help page change and enforcing the change. While I would love new fields for the format, we also need to be realistic - this will be a very low priority most likely. Sometimes finding an acceptable alternative is better than achieving nothing. And changing the rules for German (or European books) does not stop us from also adding the fields when it becomes possible. [[User:Anniemod|Annie]] 03:55, 26 November 2019 (EST)
::::::::Then at least begin to convert inches to millimeters correctly. See above.--[[User:Wolfram.winkler|Wolfram.winkler]] 07:22, 27 November 2019 (EST)

== Replacing 'our' cover images with links ==

There were two submissions by Susan [http://www.isfdb.org/wiki/index.php/User_talk:Ofearna O'Fearna] to replace images we have on our servers with ones that have a higher resolution but are based on her server. I'd think it's our policy to keep to 'our' images if we have them, but wish this assumption to be confirmed (or disconfirmed). Thanks, [[User:Stonecreek|Stonecreek]] 11:09, 19 November 2019 (EST)
:I would keep the ones here since we have control over them that way. If ours are really low resolution, we could always upload a new version that is as high a resolution as our policies allow. ···[[User:Nihonjoe|<font color="darkgreen">日本穣</font>]] · <small>[[Special:Contributions/Nihonjoe|<font color="blue">投稿</font>]] · [[User talk:Nihonjoe|Talk to Nihonjoe]]</small> 13:11, 19 November 2019 (EST)

:: As I recall, the main reason why we originally had a preference for ISFDB-hosted images was stability. Our image backups are publicly available on Google Drive, so they are likely to survive and be recoverable even if the main ISFDB server were to go up in flames for whatever reason. On the other hand, images hosted by a third party can be suddenly replaced/removed by that party (think Amazon) or simply disappear if the site dies. Every few weeks (sometimes every few days) I come across dead author sites, which serves as a reminder of how fragile the Web is even in 2019.

:: That said, if we have reason to believe that a given Web site is very stable and won't disappear if the owner [https://en.wikipedia.org/wiki/GAFIA "gafiates"], it may tip the scales in the other direction. [[User:Ahasuerus|Ahasuerus]] 13:25, 19 November 2019 (EST)

::: A link to the better image added to the notes is also an option if a better image cannot be created based on our rules. Or if we ever get to adding Web sites to publications, it can go there. On the other hand, Susan's site had been around for a very long time and I had never seen it going down (short of small blimps -- it is a server after all). I'd still probably keep the local one unless it is so blurry that it is almost unusable - if you cannot read the small text on a cover because it is too blurry, anything that actually is readable will be better, even if it is not local. [[User:Anniemod|Annie]] 20:14, 19 November 2019 (EST)

== Multiformat magazines and series grids ==

We have two separate ways to record magazines that publish their issues in more than one format (print + ebook for example or webzine + print + ebook).
* Separate series - 1 per format. This becomes a problem if one of the format is discontinued - someone needs to know to look for the other series. And if one of the two formats does not exist from the beginning, it looks incomplete. Plus the series are almost never kept in parallel ([http://www.isfdb.org/cgi-bin/seriesgrid.cgi?35233 example] and [http://www.isfdb.org/cgi-bin/seriesgrid.cgi?26273 its digital brother].
* One series, all formats merged into a single early record. This can make the grid look heavy (and repetitious) but gives the full picture of the magazine. [http://www.isfdb.org/cgi-bin/seriesgrid.cgi?31623 example] or [http://www.isfdb.org/cgi-bin/seriesgrid.cgi?36993 this one] (that last one used to be in two series but they were so mixed that instead of splitting completely, I merged awhile back).
Which one is used depends on the editor who sets the series basically - so we have both all over the place (and sometimes the wrong formats end up in the wrong place when someone does not pay attention). It is probably a good idea to at least try to decide what the standard should be. :)

I prefer the second way - especially now that we show the non-common formats so it will be clear why we have multiples and we can easily clone magazines. What does everyone think? [[User:Anniemod|Annie]] 23:14, 19 September 2019 (EDT)

: To slightly paraphrase what I wrote over on the [[Community Portal]] a few minutes ago:

: As I recall, one of the main reasons why we originally had different series for different magazine formats was that the software didn't let you clone magazine/fanzine issues. However, the software was changed in mid-2018 -- see {{FR|745}} -- so it's not longer a concern. At another point we changed the software to display different formats on the Grid page intelligently, which addressed another issue with multi-format magazine series.

: Given these software changes, I think it should be safe to adopt a "one magazine -- one series" standard. [[User:Ahasuerus|Ahasuerus]] 17:35, 5 December 2019 (EST)
::I'm good with that. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 17:22, 11 December 2019 (EST)

== Date Precedence with '00' Dates ==

When setting the first date of publication for a title record, what do we want to use when date options include dates with "00" in the date? As I see it, we have two straightforward options and one more complex:
#Specific dates have precedence: If one publication is dated "2019-12-11" and another "2019-12-00", we use "2019-12-11". If one publication is dated "2019-12-00" and another "2019-00-00", we use "2019-12-00". 
#General dates have precedence: If one publication is dated "2019-12-11" and another "2019-12-00", we use "2019-12-00". If one publication is dated "2019-12-00" and another "2019-00-00", we use "2019-00-00".
#General dates have precedence, except when the specific date is "01": If one publication is dated "2019-12-00" and another "2019-00-00", we use "2019-00-00". However, if one publication is dated "2019-01-00" and another "2019-00-00", we use "2019-01-00". The principle here being if a publication has an "01" in the date, that is the earliest month (or day) possible.
To date, we are not consistent. We now have cleanup reports that find date issues so it would be good to come up with an agreed upon standard before problematic records get fixed in different ways. I would recommend the first one. Yes, if one date is "2019-12-11" and another "2019-00-00", the second one could have been published prior to the first. However, if it was "2019-02-00" and another "2019-00-00", it's a good chance the more specific one was indeed the first one. Thoughts? --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 18:29, 11 December 2019 (EST)
: Exact date take precedence - this is the earliest date we know the book had actually been published in. The more exact, the better. So 1984-12-12 beats 1984-12-00 beats 1984-00-00. If one of the inexact ones get updated later and becomes the earliest, we change the dates of the associated other titles (a parent created because of a pseudonym); if the change comes from a previously inexactly dated pub, we adjust all titles associated with it.
: PS: The software now list 00 before 01 in pub tables and author lists and so on - which leads to translations bubbling up ahead of their originals for example (among other things - see [http://www.isfdb.org/cgi-bin/title.cgi?11 Endymion] for an example - both the Bulgarian and the Dutch publications lead the table - I would expect the first edition to actually lead it) in the table of publications - which always trips me up. If we agree on giving preference to exact dates, this will also need to be adjusted a bit eventually. At the same time, when you are adding a publication, you get a warning that your date is more exact (similar to how you get one that it is earlier than the one we have -- so it seems like we want the exact ones to win). [[User:Anniemod|Annie]] 18:42, 11 December 2019 (EST)
::Annie said it better than I could. Exact dates should have precedence. ···[[User:Nihonjoe|<font color="darkgreen">日本穣</font>]] · <small>[[Special:Contributions/Nihonjoe|<font color="blue">投稿</font>]] · [[User talk:Nihonjoe|Talk to Nihonjoe]]</small> 18:57, 11 December 2019 (EST)
:::Not a fan of exactness - too confusing:) Use the numerical ordering of no 2. : 2019-00-00 comes before 2019-01-00. More intuitive if you ask me. And if I'm not mistaken, easier to code than no.1. There's no difference between 1 and 2 for what no. of edits are concered, since equal chances you get to update dates anyway if a more exact date gets known. [[User:MagicUnk|MagicUnk]] 19:14, 11 December 2019 (EST)
:::: So should we just delete all dates from the titles then? If we have 20 stories in 2019, you want to just record them as 2019-00-00 and be done with it and never try to order them per first publishing date - and as soon as a publication is recorded as 2019-00-00 that to become our date for the story no matter what else we may know about it? Even if the originals have dates, the first translations with no date that matches the year will reset it again to 00-00. If we accept the inexact dates taking precedence, we are basically saying that dates and months do not matter on the title level - we may as well change the software to strip them and be done with all that - because otherwise it will be a mix and match and weird order on all pages between the 5 titles we know the dates of and the 5 we know only the year (so the bubble up). I am against that - strongly against that. See again Endymion on how it looks under the 00 taking precedence... :) [[User:Anniemod|Annie]] 19:24, 11 December 2019 (EST)
::::: I'm in favour of exact dates, so option 1. --[[User:Willem H.|Willem]] 06:42, 12 December 2019 (EST)

:::::: Let's consider the following, admittedly somewhat uncommon, scenario. Suppose a book has two editions. We know that the first edition was published at some point during 1984. We also know that the second edition was published in October 1984. Which date will we use if we go with option 1, i.e. "specific dates have precedence"? [[User:Ahasuerus|Ahasuerus]] 14:55, 12 December 2019 (EST)

::::::: It's not as uncommon as one would think: the second printing may be dated in a given and PVed book, but we have no PV for the first printing, and know only the year of publication. But in principle, exact dates would be better. Christian [[User:Stonecreek|Stonecreek]] 15:20, 12 December 2019 (EST)

:::::::: Wouldn't it have been nice if we had the printing rank/edition exposed somewhere so we can use it for sorting :) I know we have an FR on that somewhere :) 
:::::::: On the question though - it may happen but we need to balance it with the cases where we do have the first edition dated and later ones are just years - regardless of how we chose, this table will look weird for some books unless we manage to get the printing rank into the sorting... Maybe add a checkbox "first printing" to be used for first printing of an edition and give it preference this way? But then the Bulgarian Endymion above will also have it clicked anyway so that won't help much. And showing non-variants first ay backfire when we have the variant published earlier legitimately (two-named books and the second one winning based on the "most popular" title. It almost feels like for the title list of pubs, we need to be able to manually assign order when the default rules fail... [[User:Anniemod|Annie]] 15:48, 12 December 2019 (EST)

::::::::: Aren't we mixing two discussions? 
:::::::::#Determining what date goes into the title date field, and,
:::::::::#Sorting order of the publications.
::::::::: For the former, my preference is to use the numerical order. So, when there exists a publication with 00, that takes preference. (that's what I've been doing all this time btw, and got approved by moderators unchallenged up till now...)
::::::::: For the latter, I'm rather impartial, since that is only a display thing, but my pref is obviously that the 00 goes first, even if this creates weird stuff from time to time - cfr. the Endymion example above (and yes, I realize it may create inconsistencies between title date and pub date display order if we'd choose two different options for title date, resp pub display order)
::::::::: Do note that there exist translations that have legitimately been published earlier than the first original title (there are know Dutch translations of an orignal English Vance title that have been published first. Just sayin' :)
::::::::: On yet another note, if the printing order/rank FR would be implemented, we'd need to consider where to position 'unknown' dates. It often 'annoys' me to see 'unknowns' bunched together at the bottom of the pub list when I know for sure that eg the majority is situated at the beginning of the list, evidenced by a pre-2007 ISBN, or pricing f.e. --[[User:MagicUnk|MagicUnk]] 16:29, 12 December 2019 (EST)

:::::::::: So just to make sure we are on the same page here. A story is originally published in a daily science fiction magazine on 2017-02-12 (thus giving us exact date on first publication). A chapbook/anthology containing it is published later in 2017 but we do not have a month or a date (because we missed it and it was limited so we kinda lost the date when we finally found it in late 2019). Do you really want that story to now have the date of 2017-00-00 when we know the date perfectly well? Why would we hide data that we have? And if we do it here, what is the point of ever having dates for any titles? [[User:Anniemod|Annie]] 17:05, 12 December 2019 (EST)

:::::::::: We should keep title record date & pub sort order separate discussions. While the same principles apply, the first is easy to handle now, the second requires software mods and doesn't actually require the same answer (if we get a printing rank, there is no need to sort by date for the same editions). Past practice is not helpful either as we have been inconsistent (hence this discussion). Translations are also irrelevant as they have separate rules (parent is always dated by first appearance in native language even if translation published first). --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 17:20, 12 December 2019 (EST)

::::::::::: So why are we using the specificity of the date as a criteria for establishing the earliest date? The title date should be set to the date of the first printing of the first (or earliest known) edition. Only if the identification of this publication is not known does this discussion come into play and a number of the arguments become non-issues. ../[[User:Holmesd|Doug H]] 23:43, 12 December 2019 (EST)

(unindent) A little bit of background re: "the printing rank/edition exposed somewhere so we can use it for sorting" mentioned earlier. {{FR|794}}, "Add a 'printing' field to publication records", was created back in 2015 to address this need.

The main problem that I ran into is that the definition of "printing" can be vague. A popular book which has been published by multiple publishers using multiple formats can easily have half a dozen "first" printings: "first printing of the Dutton edition", "first printing of the Ace paperback edition", "first printing of the Italian edition", etc. If a title is associated with 6 "first printing" publications published over the course of 20 years, sorting them by their "printing" number would create a mess. In addition, some publishers (like Ace in the 1980s) occasionally reset printing numbers, which creates a difference between "stated printing" and "actual printing".

From a purely technical perspective, adding a new field to publication records would be straightforward, but first we need to decide how we are going to use it. [[User:Ahasuerus|Ahasuerus]] 10:54, 13 December 2019 (EST)

: Printing rank is only important in conjunction with a year and publisher though - to allow us to sort the 20 0000-00-00 or the first and second printing in 1979 by Ace. Sort by "date, publisher, rank" is how I think we should use it. Which will sort the editions from the same publisher. Still need to figure out the dates :) The other case we need the printing for is "I hold undated 23rd printing of a book we have 17 printings of. How do I know that we do not have 23rd?" Most of the times, new editors just add it again and a moderator need to open all 17 and read through notes because the statement can be anywhere in the notes... Older editors do their own research but it is tedious.) So yes - that won't solve the date problem completely - but it will help a bit. Visually if nothing else (and if we are adding it, it needs to bubble to the pub table on the titles or we are back to square one) And off on a tangent I went again. :) [[User:Anniemod|Annie]] 13:02, 13 December 2019 (EST)

:: Do we know how many "00" title dates (ie titles with dates that have one or two 00's) for which there's a more detailed publication date available in the first year of publication (examples: if title date is 2019-00-00, pub dates with eg 2019-05-00 or 2019-08-25, and if title date is 2019-05-00, pub dates with eg 2019-05-26) we are talking about?

:: On the publication ordering; can we have an additional field 'Printing' (as printed in the book)? Even if we can't figure out how to properly sort pubs (with all the different corner cases and whatnot), that information in and of itself is useful, I'd think. Ahasuerus, if we'd agree to add such a field, how time-consuming would it be to add? Just thinking if we'd just have that field added, that it would already be a big help, and a first step towards proper sorting. [[User:MagicUnk|MagicUnk]] 13:48, 13 December 2019 (EST)

::: It's not hard to add a single field to publication records. However, we really need to define what we will be using it for first. Will it be a strictly numeric field with the software ensuring that only numbers 1 through 10000 are allowed? Or will we allow arbitrary text like "1st trade paperback printing"? Also, will we only use this field when the printing number is explicitly stated in the book or will we also use it when we derive the number from circumstantial data and secondary sources? [[User:Ahasuerus|Ahasuerus]] 17:10, 13 December 2019 (EST)

:::: I would only allow numerical field, and allow derived data as long as it's referenced in the notes where it came from. I don't think there's need to allow "1st trade paperback printing", since the printing field would be on pub record level, hence '1' in that field would go into the 'trade paperback' edition record. [[User:MagicUnk|MagicUnk]] 17:55, 13 December 2019 (EST)

:::: It can get fishy though if you have a 1st printing of a 1st edition tp, and a 1st printing of a 2nd, revised, tp edition (with (almost) no discernible differences between the two editions, it can get confusing if you have twice 1st printing... [[User:MagicUnk|MagicUnk]] 17:58, 13 December 2019 (EST)

::::: Interesting points, but I would recommend a separate Community Portal discussion of this FR. [[User:Ahasuerus|Ahasuerus]] 12:12, 14 December 2019 (EST)

::: If we don't determine these things up front, we may end up changing things later on, e.g. we may decide to split the field into a "state printing" field and an "assume printing" field, which will require a lot of cleanup. [[User:Ahasuerus|Ahasuerus]] 17:10, 13 December 2019 (EST)

(unindent) I have been thinking about the original issue, i.e. "general dates vs. specific dates" for the last couple of days. My current thinking is that the most important criterion is ''accuracy''. If we have a good reason to believe that the more specific date is the first date when the title was published, then we should use the more specific date as the title date. If, however, we are ''not'' sure that the more specific date is the date of the first publication, then we shouldn't use it.

We should be able to stand behind what we claim. If all we know is that a title was first published in 2019, we shouldn't be using the more specific date of a possibly-not-first printing. Of course, if the more specific date is January 2019, then it's guaranteed that the title first appeared in January even if the pub is not the title's first appearance, in which case we can use it. [[User:Ahasuerus|Ahasuerus]] 17:29, 13 December 2019 (EST)
:I'm good with that approach. That makes a lot of sense to me. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 18:43, 13 December 2019 (EST)
:: Yep, that makes sense. Will make cleanup reports a bit harder to work through but that is what we have ignore for :) [[User:Anniemod|Annie]] 18:47, 13 December 2019 (EST)

== A Dutch translation of an English original has a French parent ==

Hello, I came across what I believe is a nonsensical situation: this {{t|1380637|Dune omnibus}} has a French parent. I wanted to break this relationship so that both the French and Dutch omnibuses could stand on their own (since there is no English original they can be varianted to), but according to a moderator this is how things are done, quote '' 'the first language of a title earns the status of a parent' '' - even if the end result is a nonsensical Dutch translation of an English original that is listed as translated out of French. Comments? Pointers to relevant rules - if any? Thanks in advance! -[[User:MagicUnk|MagicUnk]] 18:15, 19 December 2019 (EST)
: But they have the same contents, right - which is our definition of varianting? So why would we not variant them? [[User:Anniemod|Annie]] 18:20, 19 December 2019 (EST)
:: Because it now says on Frank Herbert's page that the Dutch one is a ''translation'' of the French, which is a false/wrong statement.
:: Also, you could turn that around, and say why would we variant them? - I guess there's no rule forcing us to variant in these kind of cases, or is there? [[User:MagicUnk|MagicUnk]] 18:29, 19 December 2019 (EST)
::: Dates - the earliest one becomes a parent (except for special cases). 
::: We may want to clean up the UI but I am against NOT connecting two books that have the same contents. :) [[User:Anniemod|Annie]] 18:31, 19 December 2019 (EST)
:::: Ugh. Ugly... what about having an English title (without pub) that these two are varianted to? After all, there are quite a few titles out there that are listed as '' '''Only''' appeared as:'' [[User:MagicUnk|MagicUnk]] 18:36, 19 December 2019 (EST)
::::(I mean, ugly as it looks right now :)
:::::I made {{T|2663617|this}} the parent of both. The original works were published in English. While there was never an English omnibus of only the first two (at least that we have recorded), showing that way is the least astonishment to any users. It also properly shows that both languages' translations were of the English. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 18:59, 19 December 2019 (EST)
:::::: I am fine with that - as long as they stay connected :) [[User:Anniemod|Annie]] 19:04, 19 December 2019 (EST)
::::::: Very nice. I like it that way. Thanks! [[User:MagicUnk|MagicUnk]] 19:11, 19 December 2019 (EST)
:::::::: I'm trying to follow the logic of this. So if I have an English omnibus of 3 Jules Verne books that were never published together - I should create a dummy French title to act as a parent for the omnibus - even though each of the three contained stories will each be varianted to their French originals? ../[[User:Holmesd|Doug H]] 19:36, 19 December 2019 (EST)
::::::::: I would not - until there is a Russian version of the exactly same omnibus. I think we should just change how the UI looks in these cases instead of creating the empty titles because of the way we word the connection but... I can live with some empty parents in such cases. [[User:Anniemod|Annie]] 20:03, 19 December 2019 (EST)
:::::::::: Agreed. This is a special case. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 21:29, 19 December 2019 (EST)
::::::::::: In my opinion this isn't. We are talking about omnibuses of translations, not translations of omnibuses. The contents should be linked to their originals as variants because that's how we currently do translations. It could change at some point. Varianting two omnibuses because they happen to have chosen the same contents is a different story. Would a second omnibus in the second language variant to the same place if it contained the same titles, but different translations? I'd argue that, in general, omnibuses shouldn't variant to other omnibuses. Even within a single language. ../[[User:Holmesd|Doug H]] 08:18, 20 December 2019 (EST)

:::::::::::: "Would a second omnibus in the second language variant to the same place if it contained the same titles, but different translations?" - Yes of course. Why wouldn't it? They won't get merged (they would if the name, title and the translators were the same) but they will become variants. We always do variants based on having the same contents - same novel, same set of stories and so on. Why would omnibuses be any different? On the title level, this is a collection/omnibus of the same X titles and nothing more - from ISFDB perspective this is the definition of a parent/variant relationship. Or am I missing something in what you are saying? [[User:Anniemod|Annie]] 12:53, 20 December 2019 (EST)

::::::::::::: (Trying to reconstruct a line of thought backwards to make an argument ...) A translation variants to the original because it is the 'same' content, subject to a translators intentions. Two different translations under the same title are, however, separate titles because they have different translators and actual content. Sometimes the content difference is the only way to tell the difference between two anonymous translations. The use of variant as a link to the source is a substitute for having a different type of link for translations. There is no variant relationship established between the two translations.  
::::::::::::: A work under a different title variants to the 'original' (oldest or best-known) title. However, if another version is sufficiently different, it gets its own title, usually with notes saying not to merge the two. This new title is not varianted to the original because it is not the same. So should two omnibuses that differed only in which version (original or edited) be varianted together? Should two omnibuses that contain the same novels but different translations be varianted together? If the first is no because the content is different, shouldn't the second be no as well? A specific example - [http://www.isfdb.org/cgi-bin/pl.cgi?324793 The Works of Jules Verne] and [http://www.isfdb.org/cgi-bin/pl.cgi?305762 Amazing Journeys] contain translations of the same 5 novels. Each corresponding novel points to a different title because the translator is known for one set and not the other. Should these be varianted now, or only if (and when) we find the translations match? (This is the translation thread for wondering why we variant omnibuses. This leaves out the problems with illustrations, introductory notes and essays which may differentiate omnibuses but not be correctly, completely or accurately recorded in content. It just seems that the overhead in matching omnibuses isn't worth the gain in cross-referencing.) ../[[User:Holmesd|Doug H]] 15:11, 21 December 2019 (EST)

== Help: Screen: MakeVariant ==

Can the help for [http://www.isfdb.org/wiki/index.php/Help:Screen:MakeVariant Help: Screen: MakeVariant] be changed from ''Two title records are variants if they are in fact the same story, but have either a different title, or '''a different author'''.'' to something that means a different presentation of the author's name, rather than a different person. ../[[User:Holmesd|Doug H]] 15:15, 21 December 2019 (EST)
:Updated to "Two title records are variants if they are in fact the same story, but have either a different title, or use an author pseudonym." ···[[User:Nihonjoe|<font color="darkgreen">日本穣</font>]] · <small>[[Special:Contributions/Nihonjoe|<font color="blue">投稿</font>]] · [[User talk:Nihonjoe|Talk to Nihonjoe]]</small> 17:30, 23 December 2019 (EST)
:: Thanks. ../[[User:Holmesd|Doug H]] 23:53, 23 December 2019 (EST)
:::I changed the wording to "or use different credits for the author's name". I also went through and replaced pseudonym throughout the whole page. The software was changed to call them alternate names as many times the ISFDB canonical name is the pseudonym and the alternate name is the author's real name. The help should reflect what the software uses. Our help isn't always the best for new users, but it needs to be at least consistent with what they find on the screen. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 09:57, 28 December 2019 (EST)
::::That works. Thanks! ···[[User:Nihonjoe|<font color="darkgreen">日本穣</font>]] · <small>[[Special:Contributions/Nihonjoe|<font color="blue">投稿</font>]] · [[User talk:Nihonjoe|Talk to Nihonjoe]]</small> 22:16, 30 December 2019 (EST)
Templates used on this page:
Template:FR
Template:Isfdb-rules-and-standards-archive-header
Template:Isfdb-rules-and-standards-archives
Template:Linkcolor (protected)
Template:P (semi-protected)
Template:R&S Archive Header
Template:T (protected)
Return to Rules and standards discussions/Archive/Archive17.
Retrieved from "http://www.isfdb.org/wiki/index.php/Rules_and_standards_discussions/Archive/Archive17"
View source

From ISFDB

Views

Personal tools

Navigation

Search

Toolbox
