ISFDB:Community Portal

From ISFDB

(Difference between revisions)
Jump to: navigation, search
(Moderator note on Publisher Edit: FR created)
(Clarkesworld - merging the two separate series: new section)
Line 1,894: Line 1,894:
:: I must have missed it back when I was adding the Moderator Note field to Edit pages. {{FR|1326}} has been created. Thanks! [[User:Ahasuerus|Ahasuerus]] 16:47, 4 December 2019 (EST)
:: I must have missed it back when I was adding the Moderator Note field to Edit pages. {{FR|1326}} has been created. Thanks! [[User:Ahasuerus|Ahasuerus]] 16:47, 4 December 2019 (EST)
 +
 +
== Clarkesworld - merging the two separate series ==
 +
 +
I want to merge the [http://www.isfdb.org/cgi-bin/pe.cgi?35233 Clarkesworld (print issues)] and [http://www.isfdb.org/cgi-bin/pe.cgi?26273 Clarkesworld Magazine] series (merging the Editors under them). The issues have the same contents, the only difference is the format and the grid now shows the uncommon formats so it will be clear what is what... Plus it won't look as if we are missing an issue altogether when we have it in only one of the formats (and now that we can clone magazines, people can clone for the other formats instead of doing all the work because they did not realize the issue is actually already in). Does anyone see a reason why not? [[User:Anniemod|Annie]] 17:00, 4 December 2019 (EST)

Revision as of 22:00, 4 December 2019


ISFDB Discussion Pages and Noticeboards
Before posting to this page, consider whether one of the other discussion pages or noticeboards might suit your needs better.
Help desk
Questions about doing a specific task, or how to correct information when the solution is not immediately obvious.
• New post • Archives
Verification requests
Help with bibliographic, image credit, and other questions which require a physical check of the work in question.
• New post • Archives
Rules and standards
Discussions about the rules and standards, as well as questions about interpretation and application of those rules.
• New post • Rules changelog • Archives
Community Portal
General discussion about anything not covered by the more specialized noticeboards to the left.
• New post • Archives
Moderator noticeboard
Get the attention of moderators regarding submission questions.
 
• New post • Archives • Cancel submission
Roadmap: For the original discussion of Roadmap 2017 see this archived section. For the current implementation status, see What's New#Roadmap 2017.



Archive Quick Links
Archives of old discussions from the Community Portal.


1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · 10 · 11 · 12 · 13 · 14 · 15 · 16 · 17 · 18 · 19 · 20 · 21 · 22 · 23 · 24 · 25 · 26 · 27 · 28 · 29 · 30 · 31 · 32 · 33 · 34 · 35 · 36 · 37 · 38 · 39 · 40 · 41 · 42 · 43 · 44 · 45 · 46 · 47




Contents

The Warrior's Apprentice Baen edition cover art

Hi, I merged the existing cover art title credited to Alan Gutierrez with the other one credited to Gary Ruddell: the cover artist was identified as Ruddell & the entries for the two printings preceding the 7th thus must have been erroneous. There was no note for those as to where the cover art credit stemmed from. Christian Stonecreek 10:10, 2 September 2019 (EDT)

The assumption is that unless otherwise stated it is from the pub. It would have been better to have checked with the verifiers before doing this. Willem's response to TAWeiss (see this discussion) implies the cover art for his printing was credited as Gutierrez in the publication. It is not unknown for publishers to change the cover and forget to update the credit until a later printing. You can explicitly ask him if you wish to double check, but otherwise, this needs to be reverted and a variant established instead. -- JLaTondre (talk) 10:18, 2 September 2019 (EDT)
I unmerged the titles again, added the right credit and varianted it to the Ruddell entry. Also added pub notes. --Willem 10:45, 2 September 2019 (EDT)

Handling erroneous tags

The way the current version of the ISFDB software ("ISFDB 2.0") works, almost all types of database changes are entered as "submissions" and have to be approved by a moderator. The major exceptions are verifications, votes and title tags. They are all user-specific, which is why Al and I originally thought that we wouldn't need moderator oversight for them. In the case of title tags we were also leveraging other Web sites' (Amazon, Goodreads, etc) experience which suggested that "crowdsourcing" tags worked well even without moderator oversight.

Overall it has worked reasonably well with a few caveats. First, we are primarily a bibliographic database, so tags like "read in 2013" are not something that we normally want to display to the world at large. A few years ago we got around this problem by letting moderators change tag status to "private".

Second, we never reached the volume that is required to make "crowdsourced" tags reliable. The vast majority of the 7% of our title records that have tags have been tagged by just one or two people. An incorrect tag entered by a single user is not too bad when dozens of other users have entered valid tags, but it becomes a problem when there are no valid tags to offset it.

Based on Christian's recent experience with incorrectly tagged titles, I would like to propose that we create a new moderator-only Web page. It will display a list of currently entered user/tag pairs for the selected title record, e.g.:

This will let moderators contact taggers and ask them about questionable tags. The proposed Web page will also let the reviewing moderator remove invalid tags for users who are not moderators.

How does it sound? Ahasuerus 12:29, 3 September 2019 (EDT)

I'm not really clear on tags, having never used them here (either entry or following). If you put this on the moderator's forum, I'd guess you wanted to know if such a tool were useful, but on a public forum I'm thinking you're asking if editors want moderators to perform this function. Doug H 08:18, 4 September 2019 (EDT)
Significant software changes are usually discussed on the Community Portal even if they mostly affect moderators. You never know when a non-moderator may notice a potential pitfall. Ahasuerus 12:48, 4 September 2019 (EDT)
I'm not sure about adding policing of tags to the list of moderator tasks, but as a tool for determining something and correcting it, it beats direct database manipulation. Doug H 08:18, 4 September 2019 (EDT)
It's possible to delete erroneous tags directly, but I should have mentioned that I haven't done it in years. Direct database manipulations are risky, so I rarely attempt them. Ahasuerus 12:52, 4 September 2019 (EDT)
I'd suggest that the deletion of a tag should be 'logged' for the Changed Primary Verifications. Doug H 08:18, 4 September 2019 (EDT)
Keep in mind that title tags are associated with titles, not publications. Title changes (edits, variants, etc) are not captured by the Changed Primary Verifications report at this time. Changes to tags would be even more difficult to link to verified publications because tags do not go through the standard submission approval process. Ahasuerus 12:45, 4 September 2019 (EDT)

(unindent) Seems good to me. In addition to this, two things has always bothered me as far as tags were concerned : 1) the fact that many "private" tags do appear from time to time, drowning the others completely (see here for instance); Linguist 10:43, 4 September 2019 (EDT).

Is the problem with this author the fact that tags like "C1 Nanzan 52" can be viewed by all users? If so, then a moderator can change their status from "Public" (their current status) to "Private", at which point only the tagging user will be able to see them. Ahasuerus 12:40, 4 September 2019 (EDT)
Oh ! I hadn't been aware of that… I now sadly realize that being a moderator doesn't mean being omniscient… ;o( ! Linguist 04:14, 5 September 2019 (EDT).

and 2) the number of quasi-identical tags (e.g. ghost / ghosts, werewolf / werewolves, fish-men / fishmen, etc.) which should be merged (if only it were possible…). Linguist 10:43, 4 September 2019 (EDT).

FR 911, "Allow moderators to edit and merge tags", should help address the issue of merging tags. We'll get to it yet! :-) Ahasuerus 12:42, 4 September 2019 (EDT)

But I suppose we'll just have to grin and bear it… Linguist 10:43, 4 September 2019 (EDT).

Do we really want to enhance tag support? What if we would not have any tags at all? Would that be a big loss? - or would it actually be a win - evil grin -:)? As far as I'm concerned, there's not much benefit in tagging, let alone start moderating them. Another argument against ISFDB tags altogether is the nonexistent support for them from our user base (see the volume - tagging is available, but just not used by our users - exceptions notwithstanding). MagicUnk 11:39, 4 September 2019 (EDT)
I should note that the fact only 7% of our titles (116K out of 1.66M) are tagged is a bit misleading. Certain title types - covers, essays, interior art, etc -- are rarely tagged for various valid reasons and variant titles can't be tagged at all. The 206,000 tags that we have is a fairly significant number since we have 178,000 novels and 464,000 short fiction works. Ahasuerus 13:01, 4 September 2019 (EDT)
How many of those tags are coming from the robots (Fixer and the older ones)? Annie 13:38, 4 September 2019 (EDT)
Well, I am responsible for 70,591 of the 206,000 tags that we have on file. Since most of my tagging is related to Fixer's activities, I guess the answer is "Around one third"?
Also, as I mentioned during the last iteration of this discussion, I find tags to be particularly useful in borderline cases like "magical realism", "surrealism", etc. It's a quick way to indicate why the title is in the database. (Of course, there are times when things are even muddier and I end up adding a note to the record explaining what we know about the title and what our sources are.) Ahasuerus 15:38, 4 September 2019 (EDT)
I was just curious - expected it to be even higher :) I agree that they are useful for these cases - I just do not want to end up in a "this is surrealism, no it is "magical realism" kinda wars. As long as we agree on what is removable and what is better to stay on, I am all for it. And we do need a way to clean after both mistakes and after non-so-nicely done tags (for one reason or another). Annie 15:45, 4 September 2019 (EDT)
True, moderators will need to be careful. Even common words may have different denotations when used by different people. For example, when a romance reader says that a story is a "fantasy", it may be a reference to "erotic fantasy" or to a trip to a billionaire's private tropical island. Back when Fixer was just starting, it took me a while to figure out why he was grabbing so many non-SF romance/erotica books... Ahasuerus 09:21, 5 September 2019 (EDT)
Implementing moderation is not going to change that (au contraire). We should just kill tags outright as our active editors base is just too small to make it viable. I would argue that we need to grow our editor base first and encourage them to actively start tagging before thinking in implementing additional tag functionality. Just my 2cents though MagicUnk 11:39, 4 September 2019 (EDT)
Well, it would help a lot! And tags are a wonderful way for users to become aware of titles they may be interested in, that's the reason they were invented for. Stonecreek 12:03, 6 September 2019 (EDT)
The primary concern here is accuracy. There are certain areas of the database that are relatively rarely used yet we have spent a significant amount of time and effort ensuring that the data that we do have is accurate. For example, less than 1% of our titles is "non-genre", but at one point I spent multiple man-weeks cleaning up the code to make sure that the database model could adequately support non-genre titles. Ahasuerus 13:06, 4 September 2019 (EDT)
Killing something just because noone does it is a bit... premature. I am not a huge fan of tags (mainly because of how I use the DB) but they can be valuable. And if you look at 3 years ago, someone may have proposed to kill the language field as well - it was not really used either. Things change - we need one editor to make it their pet-project and our numbers explode.
On the other hand, what worries me about tags is that they can be subjective. Especially around the borders of the sub-genres. I do not want to see a moderator deleting a bunch of "fantasy" tags because they think the book is something else (and vice versa). It won't be malicious but... most of us do have somewhat strong personalities and things can get heated. :) Merging was already brought up. Annie 13:38, 4 September 2019 (EDT)
I would only delete tags that are obviously erroneous, like the two I found (see over at Ahasuerus' talk page). If the editors are still active, communication about it should be mandatory and maybe it'd be possible to install a mandatory note to be filled in for the reason of deletion. Or, let's have a mandatory note on the community portal for tags to be deleted in case of inactive editors. I don't expect to encounter masses of erroneous tags, but the ones that are in the db still need fixing, I'd say.
I think the tags are one of the advantages of ISFDB: personally I'm more interested in certain authors but am also eager to encounter new ones, and if I find somebody with an interesting theme / tag (that may possibly have gained a high voting), I'll may want to give the text a try. Stonecreek 13:38, 5 September 2019 (EDT)
I was just thinking aloud through implications -- best laid plans tend to end up in disaster some times. I am sure that noone that is here today will go into tag-editing war. A few years down the road when everyone forgets why we can moderate them? Different story. :) Mandatory notes before deletion will help. Keeping a list of deleted tags somewhere so we can restore if needed will also help. But I do agree with you in general that we need the ability to remove tags that are really really wrong. Annie 12:23, 6 September 2019 (EDT)
It would be possible to capture, store and display deleted tags along with moderator notes. However, it would take significantly longer to implement than a simple "display/remove tags" page.
One temporary compromise would be to make this functionality bureaucrat-only. We are probably talking a few dozen tags a year, which shouldn't be too onerous. Ahasuerus 13:41, 6 September 2019 (EDT)
How easy will be to change the access-levels later if we decide to - aka build for bureaucrat-only, switch to moderator-also if the numbers get too big? Annie 13:46, 6 September 2019 (EDT)
It would be a simple change. Ahasuerus 14:01, 6 September 2019 (EDT)
I wonder if changing these from Public to Private won't be a good enough alternative for now? Annie 12:23, 6 September 2019 (EDT)
Unfortunately, erroneous tags can be perfectly valid in other contexts. For example, one of the tags that prompted this discussion was "parallel universe" and we wouldn't want to make it a "private tag". Ahasuerus 13:37, 6 September 2019 (EDT)
Yeah, somehow my mind blanked that part. You are indeed right. Annie 13:46, 6 September 2019 (EDT)
Bureaucrat-only is a good compromise in my opinion. Tags are very useful for anyone interested in a special theme or a certain author, but if you'd be interested in stories that deal with parallel universes and find titles that are tagged erroneously with that label, you are bound to lose some trust. Stonecreek 14:00, 6 September 2019 (EDT)

(unindent) OK, FR 1303, "Allow the removal of erroneous tags", has been created. Ahasuerus 14:50, 19 September 2019 (EDT)

Two author reports

Do we really still need both these reports:

While I had seen entries in just the first one once or twice, it had not been for a while and it seems like a waste to go through the authors twice. Maybe time to see if we can combine them? Annie 01:56, 5 September 2019 (EDT)

Hm, that's a very good question! If I recall correctly, the original reason why they were "separated at birth" was that one of them allowed moderators to "ignore" author records while the other one didn't. However, their logic has been tweaked a few times and neither one supports the "ignore" functionality at this point.
Checking the code behind the reports, I see that one of them is a superset of the other. There are some minor display differences, but I don't see anything that should prevent us from merging them.
FR 1299 "Merge 2 'Invalid Directory Entries' reports" has been created. Thanks! Ahasuerus 13:18, 5 September 2019 (EDT)
Can we keep the format of 189 (with the working language)? :) They did make sense when we had hundreds of non-Latin entries (I think the latter was deployed when we were cleaning the accented characters from the authors' directory names(?) but I may be wrong - the other one is one of the very old ones). Annie 13:32, 5 September 2019 (EDT)
Yup, the current plan is to keep the "Working Language" column. Ahasuerus 13:55, 5 September 2019 (EDT)

(unindent) Done. The remaining report has been changed to display "Working Language" values. Ahasuerus 21:55, 4 October 2019 (EDT)

Wiki page for table of translations

I have set up a wiki page here to help differentiate translations of Cinq semaines en ballon and help editors locate the correct title to add their publication to. I'd like to use it to as a template for similar pages for most of the other (50+) titles by Jules Verne. Before replicating this, I'd like some feedback in general and on a couple of particular questions. To whit:

  1. Should the translated text be in quotes? Many of the other books include dialogue already in quotes. Doug H 10:20, 5 September 2019 (EDT)
I do not see why - it is in its own column, so does not really matter. I would not use quotes if I were you :) Annie 12:47, 5 September 2019 (EDT)
  1. Should the translation follow the paragraph structure of the published form? Some translations (e.g. Mysterious Island) begin with about five paragraphs consisting of three or four words. Doug H 10:20, 5 September 2019 (EDT)
When we know what it is, why not? Makes those translations immediately obvious.Annie 12:47, 5 September 2019 (EDT)
  1. These are currently ordered by the earliest date for the translation, with the exception of the unspecified text. Other options include alphabetically by translation (to make searching for the right variant easier), and by translator (making searching easier where the translator is known - an not 'unknown'). Another option would be to split entries by title and duplicate the translation information and sort by title alone. What order would prove most useful? Doug H 10:20, 5 September 2019 (EDT)
I like the dates order Annie 12:47, 5 September 2019 (EDT)
  1. What should the order of languages be? As an English speaker and this being an English language site, I put it first, then followed alphabetically, which happened to be purely alphabetical in this case. One option is in decreasing order of the number of translations. There's also by the number of translation/title combinations. Or even in order of the number of publications (not visible, but I have the data).Doug H 10:20, 5 September 2019 (EDT)
I like it as it is now - and the menu at the top will allow jumping down. Inside of a table - strictly by date I would say. Annie 12:47, 5 September 2019 (EDT)

Your feedback would be greatly appreciated, as I've gotten too enmeshed to have a wider perspective. Doug H 10:20, 5 September 2019 (EDT)

Some notes above. That kinda illustrates my point from a couple of days ago about editors and per project - once someone starts working on something, we end up collecting a LOT of information. :) One thing though - instead of separate pages, I will keep the different titles per language together. Think of a Russian speaking editor who is trying to sort out the Russian titles - it is a lot easier to work off one page than moving between 50 or so - especially when working on omnibuses. Which begs the question on how to split and my gut feeling is pure alphabetical per language: A-D, E-G and so on (in whatever increments we need). Annie 12:47, 5 September 2019 (EDT)
Curious about where you're going with this, or rather where you think someone is coming from. Is your hypothetical user trying to figure out which French title their Russian title is a translation of? And that the title has never appeared before - otherwise they could do a text search on the Jules Verne Summary Bibliography page - same as I do when I want to find the original French title for something like "The Clipper of the Clouds"? ../Doug H 13:07, 5 September 2019 (EDT)
Length of that page - if we get 50 titles, 100 translations per title, we will need a split somewhere. And the Russian are an easy example because they tend to have as many translations as English does. And I like seeing all titles in the same language on the same page - easy to spot what someone may had forgotten to add. :) Annie 13:11, 5 September 2019 (EDT)
Are you saying the Summary Bibliography page might get too long and need to be split? This wiki page will do nothing for that. Also, isn't your scenario covered by the Preferences - Translations - Selected? Pick Russian and view the page and see all Jules Verne's Summary Bibliography in the French with only Russian translations? While a page per language (or language group - [would it be German or Deutsche?]) makes some tasks easier, verifying its correctness would be really tough - you'd end up having to scan the 50 pages for each language. Or generate a query for periodic reviews. But the same query would resolve the issue of seeing them together. So who makes the query - the maintainer or our Russian editor? And what if I only get the Extraordinary Journey series done, what happens to the other titles, or short stories. I'm convincing myself that keeping it to one wiki page per title with all languages is preferable. How's by you? ../Doug H 14:01, 5 September 2019 (EDT)
The wiki page, not the summary page :) The point of the wiki page is to give you an easy reference, right - that does not require either DB knowledge or opening 20 pages to see the beginning translations? I may be overthinking it. If you want to go title by title, that also works. I just would prefer it to be language based and not title based (but it is not my project). And once we have it, we can always reorganize. So... just thinking aloud :) Annie 14:11, 5 September 2019 (EDT)
Ah, you were referring to your suggested single page for all Jules Verne translations, not my suggestion that the Russian editor could find a title by searching the Summary Bibliography page using a browser search to find which French title corresponded to his Russian one. Different perspectives - my approach is intended for people wanting to add a publication and helping them locate the correct title, based on the actual text, not just the title, or even the translator, given there are sometimes multiple unknowns, each with a different translation. And the only reason for not following paragraph structure was to keep the page from getting too long. :) ../Doug H 14:29, 5 September 2019 (EDT)

Internet Archive "hotlinking"

Perhaps this is a better discussion for rules or moderators but I thought everyone might like to chime in on this.

We currently detail which sites we allow images to be hotlinked from at: Template:Image Host Sites. I was wondering if we could get the Internet Archive added to this list. We already have the Open Library which is one of their projects but I was interesting adding magazine covers like:

I realize in this example Starlog it not considered fully an "in genre" magazine and thus we often do not concern ourselves with providing covers (much-less full contents) but this is just an example.

Notice there is some information about what not to link to here: https://archive.org/services/docs/api/items.html#archival-urls This is why I mentioned:

and not:

which is the target of the redirect (at least for now; presumably they do not want people linking to this as it might change)

It should also be noted this has come up on some of their online discussions before and they have approved it, e.g.:

Do we need to specifically ask them (and is someone volunteering) or can we have them added to the list of possible hotlink hosts we accept?

Thank you, Uzume 17:38, 5 September 2019 (EDT)

The linked discussion and https://archive.org/services/docs/api/items.html#archival-urls suggest that stable Internet Archives look like https://archive.org/download/<identifier>/<filename> . However, the Starlog scover scan URL linked above is https://archive.org/download/starlog_magazine-004/004_jp2.zip/004_jp2/004_0000.jp2?ext=jpg , a different format. Also, it requires a query string, "ext=jpg". Is there any kind of Internet Archive documentation about this format? Ahasuerus 16:41, 9 September 2019 (EDT)
Actually that is the filename/filepath. "004_jp2/004_0000.jp2" is the filepath inside the 004_jp2.zip file. I could not find any documentation on ext query string that seems to convert the file type. We could link to the .jp2 file but I found it did not render in my browser (so was not a good choice as an img src). You can poke around in here to get the idea how I came to the link I provided above: https://archive.org/download/starlog_magazine-004 As a test, I made this submission. Uzume 17:23, 18 September 2019 (EDT)
I am putting this on hold. We still do not have permissions to link but I will leave it so Ahasuerus can see how it looks like - although if you wanted to use it as a test, your moderator note should have added that to the link :) Annie 17:34, 18 September 2019 (EDT)
I thought there were more than adequate notes here so just linked to here in the mod note (and I did not expect it to be approved directly; thanks for holding it). As for a perhaps more realistic example (instead of Starlog which is only partially here under acquisition rules), I was thinking of something like https://archive.org/download/equality00belluoft/equality00belluoft_jp2.zip/equality00belluoft_jp2/equality00belluoft_0001.jp2&ext=jpg for 270798. Uzume 17:59, 18 September 2019 (EDT)

(unindent) I guess we have two overlapping questions here:

  • Are we allowed to deep-link to images hosted by the Internet Archive?
  • Are their images and image URLs stable?

Historically, the main problems with deep-linking have been:

  • bandwidth
  • revenue

In the not so distant some past popular sites like Wikipedia didn't want third party sites to link to "their" images because it increased their hosting costs. This issue appears to be less important now that bandwidth is less expensive.

Revenue is something that we have run into with SFE3: their sponsoring organization wanted us to link to a separate Web page which was set up to make it easier for customers to buy books.

In the case of the Internet Archive, their staff posts suggest that they do not have bandwidth or revenue problems with deep-linking. Uzume's research suggests that the URLs that he uses are at least moderately stable.

Based on the analysis above, I wouldn't be opposed to adding "archive.org" to the list of supported third party sites, although an explicit e-mail permission dated "2019" would be nice to have.

That said, do we expect a significant number of links to their site? If not, it may be easier to upload the images in question to the ISFDB server and link them. Ahasuerus 15:03, 19 September 2019 (EDT)

As a workaround, I have just been pulling Internet Archive images across to their Open Library project and then hotlinking here (since we already allow that). That works alright for books as I just have to ensure the right entry exists there but I am not sure about magazine covers which would likely not be in their Open Library project. Uzume 12:36, 22 September 2019 (EDT)

Not One of Us – magazine or fanzine?

I wonder do we need to make a decision about whether we list the all-fiction/poetry publication Not One of Us as a magazine or a fanzine? From 1986–2001 we have it listed as a fanzine, then from 2002–2018 it is alternately a magazine or a fanzine. Their website refers to it being "a hardcopy zine", with a pull-quote saying it's a "stalwart of the zine scene", yet their Guidelines page has "The editorial philosophy of the magazine...".

We also have a small problem with format, sometimes A5 but mostly octavo, although from the website's description "a digest-sized (5.5 x 8.5 inch, 52-page) publication" it is clearly octavo.

All this makes for inconsistency and I think we could present the information better. The majority of publications are unverified, so I'll spend a bit of time knocking the series into shape if we can come to a group decision on the Magazine/Fanzine question – my own preference would be for Magazine. I'm particularly looking for feedback from verifiers Hkauderer and Kevin Hardy, although I'm uncertain if either of those editors are still around. Thanks. PeteYoung 08:10, 6 September 2019 (EDT)

I would have never thought that it is not a magazine. Just as a data point, ~15 years ago (probably a bit more), Not One of Us was one of the not so many English language small magazines which were available from a distributor website that was willing to ship to Bulgaria - together with some other books from small presses. Everything else on their list of magazines was a clear magazine, this one was in the same section. Does not mean that it could not have been something else but... I probably should find the boxes with all magazines next time I am back at my mother's apartment. Annie 11:23, 6 September 2019 (EDT)

Deprecating {{A}}

In Help:Using Templates and HTML in Note Fields#Linking Templates we list {{A}} as a supported template stating:


[...]
At this time the following linking templates are supported:
Template Functionality Example
A Links to an Author record within ISFDB using the author's name {{A|Jules Verne}}

[...]

However, later in the same page at Help:Using Templates and HTML in Note Fields#Links to Other ISFDB Records we state:


[...]
If you choose to link to another ISFDB record, avoid using the following types of links:
[...]

[...]

Should we deprecate and/or update/replace {{A}}? Thank you, Uzume 19:14, 8 September 2019 (EDT)

"A" links to the search page, not to the author page itself - so if you pass "Test" as a parameter, it goes to http://www.isfdb.org/cgi-bin/se.cgi?arg=Test&type=Name&mode=exact. There is just a forward in the Advanced Search that IF there is only one result, it opens the author page instead of the results page (using the ID and not the name). Try the A template with an author that does not exist :) So A is quite safe. Annie 19:40, 8 September 2019 (EDT)
PS: If you do not believe that the template is tied that way, look at any note with it and hover over the link or view the source code :). It effectively links to the author but not by getting the name and creating a URL out of it. Annie 20:20, 8 September 2019 (EDT)
That's right. The "A" template works fine with non-Latin characters and so do all other templates. Ahasuerus 21:18, 8 September 2019 (EDT)
Oh, I never said it did not work just that it did not link by author id. The link section recommends we should link by the author id and not the author name itself (although we guarantee those are unique). Perhaps we should recommend linking by author id *or* the exact search? Also since we have redirects why not make the author lookups that use a name instead of an author id redirect to the exact search and/or at least redirect to the author pages referenced by author id (for cases that don't have Unicode issues and currently work). Uzume 15:08, 9 September 2019 (EDT)
I mean why not have:
redirect to:
to solve the problem or at least directly to (since "Ray Bradbury" stays within Latin-1) to:
So when people copy the URL it causes them to not want to link to name reference entry (because it gets redirected).
I just am concerned why the difference in the same page about how to reference an author. If it can be solved in code—so be it. Uzume 15:16, 9 September 2019 (EDT)
Let me try this again because I do not think that you read any of the messages (or clicked on any of the links. :)
We do NOT link to http://www.isfdb.org/cgi-bin/ea.cgi?Ray_Bradbury via the template. We link to http://www.isfdb.org/cgi-bin/se.cgi?arg=Ray Bradbury&type=Name&mode=exact. Which searches and then links based on the ID (to http://www.isfdb.org/cgi-bin/ea.cgi?194), not using the name.
Just go to ANY of the notes that have a name and look at where the address is pointing to. The format you are concerned with is not used at all.
Linking to an ID when the ID is not presented will mean that the lookup needs to be done during the save and replaced (as opposed to building a URL using what the user presented). Doable? Yes. But what do we do when there is no user to be linked? Now it sends you to the search page (so if one day there is one, it will connect). And how about cases where the author ID changes - who is going to update all the links? The warning for the "bad URL" is valid but the template does not use it so... it is not relevant. :) Annie 15:40, 9 September 2019 (EDT)
I think you did not read what I am trying to say (perhaps I worded it poorly) and that is there is a discontinuity in how these two situations are handled. I like the way the template links to the exact search (and forwards to the author id URL). I just think that case and the one where an author name (vs. its id) is in the "ea.cgi" link (which is discouraged) should be handled the same way. So why not make that redirect to the exact search URL (or directly to the author id URL since the exact search often ends up there anyway). This would further dissuade others from using the author name in the "ea.cgi" link as the redirect will cause the URL to not stay in the browser's address bar. That is what I meant by solve issues with code vs. my original idea to perhaps have the templates link to the author id (necessitating a change and possibly deprecating {{A}}).
I was never confused how they worked technically (I can directly read the Python and SQL code), I just feel they ought to be handled in a similar manner. Since we are on the topic if the deprecated author name "ea.cgi" (and other author page) linking. It should be possible to log such accesses (and any HTTP referer [sic]) and create something like a nightly report such that others can then investigate and attempt to rectify such inbound links from elsewhere. We might also be able to warn the user using such an inbound link and perhaps they would be able to change the external link source. Uzume 16:42, 10 September 2019 (EDT)
I did read what you said - having the template being mentioned all over the place confused the whole thing a lot though. :) Deprecating the template won't do anything for what you are trying to solve here - because the template is technically the correct way to do these links. :)
So to summarize without all the irrelevant parts and window dressing above: you propose ea.cgi to be modified so that when someone uses a name in the URL, it emulates the template and goes via search with the name (thus going for the ID link at the end). Is that the current state of the idea? Annie 17:24, 10 September 2019 (EDT)
I actually looked into this issue back when the Search software was rewritten and templates were implemented. I ran into some technical issues and ended up abandoning the effort. It may be worth trying again. Ahasuerus 17:46, 10 September 2019 (EDT)
@Annie: Yes, that is exactly what I am saying (and it applies to the other author page formats as well, like awards, alpha, chrono, etc.). It might also be useful to document the ability to link to the exact author search but I am not sure we want to support such inbound URLs. One can already see the issue of author name linkage in ea.cgi: wikipedia:Special:LinkSearch/www.isfdb.org/cgi-bin/ea.cgi (be sure to page down past the author numeric IDs; Mediawiki does not allow more complex external link searches that would let me filter those out). Uzume 17:16, 18 September 2019 (EDT)
Thanks, that's a useful URL to be familiar with. I suspect that officially supporting deep links using our Search URLs would invite problems. We have changed the URL format a few times and may change it again, so URLs are not guaranteed to remain stable. Ahasuerus 15:09, 19 September 2019 (EDT)

If we do decide to work on making redirects for these (e.g., the creation of an FR, etc.), lets not forget this needs to also be extended to series, e.g., currently this is still legal (though methinks it too should be discouraged): The Stainless Steel Rat should redirect to The Stainless Steel Rat I am not sure if there are other similar candidates. Uzume 00:35, 1 October 2019 (EDT)

Award Name Changes

The editor for Analog has announced that the John W. Campbell Award for Best New Writer has been renamed as "The Astounding Award for Best New Writer". Those in charge of two other awards have also been discussing name changes. The Gunn center has announced that the John W. Campbell Memorial Award will be renamed, but the new name has not yet been chosen. The administrators of the James Tiptree, Jr. Award have discussed changing the name and have decided not to do so at this time, though they describe their thinking as "ongoing and tentative" and the name may change in the future. I've been thinking about how we should handle these changes in the database. All three of these awards have several years of history and I would suggest that we keep the existing award pages as is for those years under the old name. Going forward I would suggest a new award page for the new name with links in the notes of each award page linking to the other. That way folks searching for either name would be able to find things. I don't know if we want to set up a new page for the Astounding award now, as it would be blank until next year when the nominations are announced. We will need to wait for the new name for the second Campbell award and for the Tiptree, only if they decide to change the name. Are there any other ideas on how to reflect this award data? --Ron ~ RtraceTalk 22:45, 8 September 2019 (EDT)

I can think of at least one award whose name has changed since it was created, the Ditmar Award. It was originally known as the "Australian Science Fiction Achievement Award". The full name that we currently use is "Ditmar Award / Australian Science Fiction Achievement Award" while the short name is "Ditmar". We could use a similar approach in similar cases, although it may become unwieldy when dealing with longer award names: "The Astounding Award for Best New Writer / John W. Campbell Award for Best New Writer" may be a bit too much.
Alternatively, we could create new award types and document the relationship in Notes. Ahasuerus 23:14, 8 September 2019 (EDT)
If that becomes highly common and complex we might eventually decide to support some sort of award relations not unlike our current pseudonym and title variant systems (I can already see where this would be very useful to support publisher relations of some sort). Uzume 17:04, 18 September 2019 (EDT)
Well... The "variant title" system lets us capture title/author information as it exists in publications as well as its "ideal" or "canonical" state. That's a good thing, but it also adds a great deal of complexity to the software.
It's been occasionally suggested that we use a similar system for other parts of the database, e.g. to capture publisher names both as they appear in publication and in their "canonical" form. It's doable, but it would require a significant amount of work, both on the software side and on the data entry side. We would also need to make sure that our design is very solid because we really wouldn't want to do re-do again. For publishers, it would mean figuring out how to handle imprints and books co-published by multiple publishers, which is liable to add extra levels of complexity. Ahasuerus 17:40, 19 September 2019 (EDT)
I understand such a change is nontrivial but we have made nontrivial changes in the past and I am sure they will happen in the future. Are we ready for this type of change now? I do not know but I thought I should bring it up as it is a possibility that impacts the issues being talked about. As a side note, I got a good laugh out of thinking about "canonical publishers" (isn't that some sort of oxymoron?). Uzume 12:30, 22 September 2019 (EDT)

Final Fantasy

I think I got them all. "The Spirits Within" is a weird one. I've seen a number of places that Dean Wesley Smith wrote the novelization (with cover images and everything), and then other places that say John Vornholt wrote it (also with cover images). Both have the same ISBN, and it hasn't been verified here, so I have no idea which might be the actual author. Any ideas which is actually correct? ···日本穣 · 投稿 · Talk to Nihonjoe 00:35, 10 September 2019 (EDT)

After digging a little bit more, it looks like Vornholt did a juvenile novelization, and Smith did an adult novelization. It would be helpful if the covers indicated this, and if Amazon didn't have the entries merged. ···日本穣 · 投稿 · Talk to Nihonjoe 02:09, 10 September 2019 (EDT)
Well, where will be the fun in that? :) Annie 02:37, 10 September 2019 (EDT)
Novelizations have always been iffy, e.g. see this UK novelization of Capricorn One vs. its US counterpart. However, things have been slowly getting worse over the last 10-20 years. For major intellectual properties, the rights owners routinely commission 2+ different novelizations for different age groups. Factor in the fact that novelizations aimed at younger children tend to obscure their authors and you end up with a big mess. Ahasuerus 10:28, 10 September 2019 (EDT)
That is highly confusing, especially since the Dean Wesley Smith adult novelization was translated to Japanese (instead of creating Japanese novelizations directly from the Japanese movie) and the NDL indicates all three publications are children's literature. Uzume 16:46, 18 September 2019 (EDT)
Wouldn't be the first time people varied on whether something was or wasn't for kids. Until we get PVs for them, we can't really do more than what we have. ···日本穣 · 投稿 · Talk to Nihonjoe 02:10, 19 September 2019 (EDT)

pb, tp and the dropdown

After explaining/clarifying for a third time this week that "pb" does not really mean paperback, it kinda reminded me that we really need to do something about this - or new editors will continue to be confused. So why don't we change the drop down values:

  • pb -> "pb (mass market paperback)" or even "pb (7'x4.25' / 18x11 cm or smaller)"
  • tp -> tp (7'x4.25' / 18x11 cm or larger)"

We do have the space (the audio formats are long) so... why not help the editors visually? Other idea for naming are welcome. Annie 16:13, 15 September 2019 (EDT)

I've always thought of pb as pocket book. Not that it is really any better defined but narrows down the argument by eliminating the trade-sized publications. ../Doug H 22:13, 15 September 2019 (EDT)
While closer, that will include a lot of Eastern European books which are too big to be called pb in the DB - even with generous exceptions (apparently we used to have bigger pockets than the Western world - or something). But still - it will be better than now (and this is only for the front end - the codes behind the scenes are fine) :) Annie 22:57, 15 September 2019 (EDT)
That's not only the case for Eastern Europe but for Western Europe as well (maybe with the exception of some islands in the West): we had this discussion a while back. So this specific dropdown would also be misleading. The best I can think of is an explaining comment that these measures are valid for (most of) the English publishing world, but may vary for other countries. Stonecreek 02:22, 16 September 2019 (EDT)
And put the comment where? :) If people will read the help pages, that is easy enough - we have the info there. They don't. So I am thinking of changing the drop down so it is easier to see that this type is not what they think it is. Annie 02:38, 16 September 2019 (EDT)
I just saw that we have that infobox right near the 'Format' field (when you come on the question mark). This one should be specified, I'd say. Christian Stonecreek 15:10, 16 September 2019 (EDT)
Sure, it is there - but people will still not look at it - or hover on it - hovering from a touch screen is a bit... problematic :) The list looks logical - and if they press "p" to get to "paperback" and see "pb", most people won't look further. Not what we wish people were doing but no reason to just hide our heads in the sand and pretend that it is not happening. The field looks self-explanatory - and most people do not read the help pages for this kind of fields. Annie 15:31, 16 September 2019 (EDT)
Which one would you select for wikipedia:Bunkobon? I usually go with "pb" since it is paperback A6. It would be nice if we had "A6" since we have "A4" and "A5". Uzume 16:52, 18 September 2019 (EDT)
You are mixing up things here - you cannot use A4/A5 for books under the current rules. Look at the help page. We have clear separation between formats for magazines and formats for books - the A4/A5 formats are ONLY for magazines so even if we had A6 in the magazines section it would not have been the correct format for a book. So yes, a paperback book as small as that one is "pb". Does not mean that we do not have a handful books of each of the A4/A5 formats (uncleaned data, magazines converted to anthologies, stuff that was just missed, special cases or 3 and so on) but technically, the magazine formats should not be used for anything besides magazines and fanzines. Until we decide to change the rules anyway.
However the thread above is not about changing the rules - it is just for providing a visual help to editors so let's not go into "let's change the formats" discussions. If you want to reopen that can of worms, start another thread. :) Annie 23:11, 18 September 2019 (EDT)
I was not confused nor soliciting for rule changes as much as just underscoring the state of things as it applies to a certain common publishing format by asking a rhetorical question (hoping to ensure such were considered). My point was to perhaps include "bunko" along with "mass market" in the description; something like:
pb -> "pb (mass market/bunko paperback; 7'x4.25' / 18x11 cm or smaller)". Uzume 12:11, 22 September 2019 (EDT)

(unindent) Getting back to the "Format" drop-down list, it would be possible to make each choice more descriptive along the lines of "tp (7'x4.25' / 18x11 cm or larger)".

However, keep in mind that we already have a few different ways of conveying this information to our users. On the publication display page we have mouse-over help for each format code. For example, if you hover your mouse over the question mark next to "pb" on this page, you will see "Paperback. Typically 7" by 4.25" (18 cm by 11 cm) or smaller, though trimming errors can cause them to sometimes be slightly (less than 1/4 extra inch) taller or wider/deeper."

When editing a publication record, the blue bubble next to the word "Format" says, among other things, "pb for 7" by 4.25" (18 cm by 11 cm) paperbacks".

In other words, we already display this information in 2 different places, although the wording is somewhat different. Displaying it yet again doesn't seem like the best way to handle the problem. Perhaps we could use the empty space to the right of the drop-down list to display a message along the lines of "Hover your mouse over 'Format' on the left for more details"? Ahasuerus 15:59, 20 September 2019 (EDT)

And my point is that people do not hover over things or read help pages for things they believe to be intuitive and clear - we can have it in 10 places, put a "hover for details" in 10 more and people still won't do it because they do not think they need details because "pb" sounds like the logical choice. People see "pb" and are done with reading - we may have it in 2 places but people just do not look there. Annie 17:00, 20 September 2019 (EDT)
I am pretty sure there is a really good British joke about how much people hover over things in here. Uzume 12:14, 22 September 2019 (EDT)
The problem is actually only the fact that in the help pb and tp is defined with the length and width and that is apparently wrong (Google translator).--Wolfram.winkler 04:37, 23 September 2019 (EDT)

Custom database query request

Earlier today I received the following e-mail request from the SF reviewer James Nicoll:

Is there a way to construct a search of isfdb so that it returns a list of the Best Novel Hugo for each year, with a list of the cover artists for the American editions of the stories in the first year of publication? (basically, looking for patterns in cover art and nominations)

The short answer is that yes, it should be possible, but it would require a custom database query. I haven't been feeling well lately, so I am not in a good position to create one. Would anyone be interested in giving it a try? Ahasuerus 14:20, 16 September 2019 (EDT)

See the following table. There are some caveats:
  • It is using the title id the award is linked to. It could be expanded to look for variants / parents in case also appeared under different form in that time frame.
  • It does not include serialization. Some of the early ones were in magazines. It could be expanded to include those, but the cover would not necessarily be for the story and the artist would likely change over the serialization.
  • It bases it being an American edition of the price being US $. It therefore ignores pubs w/o a price.
  • It does not include the Retro Hugo, but that could be included.
If any tweaks are desired to the above caveats, I will see what I can do. -- JLaTondre (talk) 21:16, 16 September 2019 (EDT)
Award Year Author(s) Title Pub Year Publisher Price Artist(s) Image
1959 James Blish A Case of Conscience 1958 Ballantine Books $0.35 Richard Powers Image
1960 Robert A. Heinlein Starship Troopers 1959 G. P. Putnam's Sons $3.95 Jerry Robinson Image
1961 Walter M. Miller, Jr. A Canticle for Leibowitz 1959 J. B. Lippincott $4.95 Milton Glaser Image
1961 Walter M. Miller, Jr. A Canticle for Leibowitz 1960 J. B. Lippincott $4.95 George Sottung Image
1962 Robert A. Heinlein Stranger in a Strange Land 1961 G. P. Putnam's Sons $4.50 Ben Feder Image
1962 Robert A. Heinlein Stranger in a Strange Land 1961 G. P. Putnam's Sons / SFBC $1.70 Ben Feder Image
1963 Philip K. Dick The Man in the High Castle 1962 G. P. Putnam's Sons $3.95 Robert Galster Image
1963 Philip K. Dick The Man in the High Castle 1962 G. P. Putnam's Sons / SFBC $1.20 Robert Galster Image
1964 Clifford D. Simak Way Station^Here Gather the Stars 1963 Doubleday $3.50 Ronald Fratell Image
1964 Clifford D. Simak Way Station^Here Gather the Stars 1963 Doubleday / SFBC $1.20 Ronald Fratell Image
1965 Fritz Leiber The Wanderer 1964 Ballantine Books $0.75 Bob Abbett Image
1966 Frank Herbert Dune 1965 Chilton $5.95 John Schoenherr Image
1967 Robert A. Heinlein The Moon is a Harsh Mistress 1966 G. P. Putnam's Sons $5.95 Irv Docktor Image
1968 Roger Zelazny Lord of Light 1967 Doubleday $4.95 Howard Bernstein Image
1969 John Brunner Stand on Zanzibar 1968 Doubleday $6.95 S. A. Summit, Inc. Image
1970 Ursula K. Le Guin The Left Hand of Darkness 1969 Ace Books $0.95 Diane Dillon + Leo Dillon Image
1970 Ursula K. Le Guin The Left Hand of Darkness 1969 Walker & Co. $4.95 Jack Gaughan Image
1970 Ursula K. Le Guin The Left Hand of Darkness 1969 Walker & Co. / SFBC $1.98 Jack Gaughan Image
1971 Larry Niven Ringworld 1970 Ballantine Books $0.95 Dean Ellis Image
1972 Philip José Farmer To Your Scattered Bodies Go 1971 G. P. Putnam's Sons $4.95 Ira Cohen Image
1972 Philip José Farmer To Your Scattered Bodies Go 1971 Berkley Medallion $0.75 Richard Powers Image
1973 Isaac Asimov The Gods Themselves 1972 Doubleday $5.95 David November Image
1973 Isaac Asimov The Gods Themselves 1972 Doubleday & Company / SFBC $1.98 David November Image
1974 Arthur C. Clarke Rendezvous With Rama 1973 Harcourt Brace Jovanovich $6.95 Hal Siegel Image
1974 Arthur C. Clarke Rendezvous With Rama 1973 Harcourt Brace Jovanovich / SFBC $1.49 Hal Siegel Image
1975 Ursula K. Le Guin The Dispossessed 1974 Harper & Row $7.95 Fred Winkowski Image
1975 Ursula K. Le Guin The Dispossessed 1974 Harper & Row / SFBC $2.49 Fred Winkowski Image
1976 Joe Haldeman The Forever War 1975 St. Martin's Press $7.95 UNKNOWN Image
1977 Kate Wilhelm Where Late the Sweet Birds Sang 1976 Harper & Row $7.95 M. C. Escher Image
1977 Kate Wilhelm Where Late the Sweet Birds Sang 1976 Harper & Row / SFBC $1.98 M. C. Escher Image
1978 Frederik Pohl Gateway 1977 St. Martin's Press $8.95 Boris Vallejo Image
1978 Frederik Pohl Gateway 1977 St. Martin's Press / SFBC $2.49 Boris Vallejo Image
1979 Vonda N. McIntyre Dreamsnake 1978 Houghton Mifflin $8.95 Stephen Alexander Image
1979 Vonda N. McIntyre Dreamsnake 1978 Houghton Mifflin / SFBC $2.98 Stephen Alexander Image
1980 Arthur C. Clarke The Fountains of Paradise 1979 Harcourt Brace Jovanovich $10.00 Paul Bacon Image
1980 Arthur C. Clarke The Fountains of Paradise 1979 Harcourt Brace Jovanovich / SFBC $3.50 Paul Bacon Image
1981 Joan D. Vinge The Snow Queen 1980 The Dial Press $10.95 Leo Dillon + Diane Dillon Image
1981 Joan D. Vinge The Snow Queen 1980 The Dial Press $10.95 Leo Dillon + Diane Dillon Image
1981 Joan D. Vinge The Snow Queen 1980 The Dial Press / SFBC $4.50 Leo Dillon + Diane Dillon Image
1982 C. J. Cherryh Downbelow Station 1981 DAW Books $2.75 David B. Mattingly Image
1982 C. J. Cherryh Downbelow Station 1981 DAW Books / SFBC $4.50 Rego Image
1983 Isaac Asimov Foundation's Edge 1982 Doubleday & Company $14.95 Joe Caroff Image
1983 Isaac Asimov Foundation's Edge 1982 Whispers Press $50.00 UNKNOWN Image
1983 Isaac Asimov Foundation's Edge 1982 Doubleday $14.95 Joe Caroff Image
1983 Isaac Asimov Foundation's Edge 1982 Doubleday $14.95 Joe Caroff Image
1984 David Brin Startide Rising 1983 Bantam Books $3.50 Jim Burns Image
1985 William Gibson Neuromancer 1984 Ace Books $2.95 James Warhola Image
1985 William Gibson Neuromancer 1984 Ace Books $2.95 James Warhola None
1986 Orson Scott Card Ender's Game 1985 Tor $13.95 John Harris Image
1987 Orson Scott Card Speaker for the Dead 1986 Tor $15.95 John Harris Image
1987 Orson Scott Card Speaker for the Dead 1986 Nelson Doubleday / SFBC $7.98 Vincent Di Fate Image
1988 David Brin The Uplift War 1987 Phantasia Press $22.00 Wayne D. Barlowe Image
1988 David Brin The Uplift War 1987 Phantasia Press $60.00 Wayne D. Barlowe Image
1988 David Brin The Uplift War 1987 Bantam Spectra $4.50 Michael Whelan Image
1988 David Brin The Uplift War 1987 Nelson Doubleday / SFBC $9.98 Richard Powers Image
1989 C. J. Cherryh Cyteen 1988 Warner Books $18.95 Don Maitz Image
1989 C. J. Cherryh Cyteen 1988 Warner Books / SFBC $9.98 Don Maitz Image
1990 Dan Simmons Hyperion 1989 Doubleday Foundation $18.95 Gary Ruddell Image
1990 Dan Simmons Hyperion 1989 Doubleday Foundation $8.95 Gary Ruddell Image
1991 Lois McMaster Bujold The Vor Game 1990 Baen Books $4.50 Tom Kidd Image
1991 Lois McMaster Bujold The Vor Game 1990 The Easton Press $45.00 UNKNOWN Image
1991 Lois McMaster Bujold The Vor Game 1990 GuildAmerica Books / SFBC $9.98 Dean Morrissey Image
1992 Lois McMaster Bujold Barrayar 1991 Baen Books $4.99 Stephen Hickman Image
1993 Vernor Vinge A Fire Upon the Deep 1992 Tor $21.95 Boris Vallejo Image
1993 Vernor Vinge A Fire Upon the Deep 1992 Tor / SFBC $10.98 Boris Vallejo Image
1993 Connie Willis Doomsday Book 1992 Bantam Spectra $22.00 Tim Jacobus Image
1993 Connie Willis Doomsday Book 1992 Bantam Spectra $10.00 Tim Jacobus Image
1993 Connie Willis Doomsday Book 1992 Bantam Spectra / SFBC $12.98 Tim Jacobus Image
1995 Lois McMaster Bujold Mirror Dance 1994 Baen $21.00 Gary Ruddell Image
1995 Lois McMaster Bujold Mirror Dance 1994 Baen / SFBC $9.98 Gary Ruddell Image
1996 Neal Stephenson The Diamond Age 1995 Bantam Spectra $22.95 Bruce Jensen Image
1996 Neal Stephenson The Diamond Age 1995 Bantam Spectra / SFBC $8.98 Bruce Jensen Image
1997 Kim Stanley Robinson Blue Mars 1996 Bantam Spectra $22.95 Don Dixon Image
1997 Kim Stanley Robinson Blue Mars 1996 Bantam Spectra / SFBC $10.98 Don Dixon Image
1998 Joe Haldeman Forever Peace 1997 Ace Books $21.95 Bruce Jensen Image
1999 Connie Willis To Say Nothing of the Dog 1998 Bantam Spectra $23.95 Eric Dinyer Image
1999 Connie Willis To Say Nothing of the Dog 1998 Bantam Spectra / SFBC $11.98 Eric Dinyer Image
1999 Connie Willis To Say Nothing of the Dog 1998 Bantam Books $6.50 Eric Dinyer Image
2000 Vernor Vinge A Deepness in the Sky 1999 Tor $27.95 Bob Eggleton Image
2000 Vernor Vinge A Deepness in the Sky 1999 Tor / SFBC $13.98 Bob Eggleton Image
2001 J. K. Rowling Harry Potter and the Goblet of Fire 2000 Arthur A. Levine Books $25.95 Mary GrandPré Image
2001 J. K. Rowling Harry Potter and the Goblet of Fire 2000 Scholastic $25.95 Mary GrandPré Image
2001 J. K. Rowling Harry Potter and the Goblet of Fire 2000 Scholastic / SFBC $12.98 Mary GrandPré Image
2002 Neil Gaiman American Gods 2001 William Morrow / HarperCollins $26.00 Kamil Vojnar Image
2002 Neil Gaiman American Gods 2001 William Morrow / HarperCollins / SFBC $12.98 Kamil Vojnar None
2003 Robert J. Sawyer Hominids 2002 Tor $25.95 Donato Image
2004 Lois McMaster Bujold Paladin of Souls 2003 PerfectBound / HarperCollins $11.99 UNKNOWN None
2004 Lois McMaster Bujold Paladin of Souls 2003 Eos / HarperCollins $24.95 David Bowers Image
2004 Lois McMaster Bujold Paladin of Souls 2003 Eos / HarperCollins / SFBC $12.99 David Bowers Image
2005 Susanna Clarke Jonathan Strange & Mr. Norrell 2004 Bloomsbury USA $27.95 Portia Rosenberg + William Webb Image
2005 Susanna Clarke Jonathan Strange & Mr. Norrell 2004 Bloomsbury USA $27.95 Portia Rosenberg + William Webb Image
2005 Susanna Clarke Jonathan Strange & Mr. Norrell 2004 Bloomsbury USA / SFBC $14.99 UNKNOWN None
2005 Susanna Clarke Jonathan Strange & Mr. Norrell 2004 Bloomsbury USA $27.95 Portia Rosenberg + William Webb Image
2006 Robert Charles Wilson Spin 2005 Tor $25.95 Drive Communications Image
2006 Robert Charles Wilson Spin 2005 Tor / SFBC $12.99 Drive Communications Image
2007 Vernor Vinge Rainbows End 2006 Tor $25.95 Stephan Martiniere Image
2007 Vernor Vinge Rainbows End 2006 Tor / SFBC $13.99 Stephan Martiniere Image
2008 Michael Chabon The Yiddish Policemen's Union 2007 HarperCollins $26.95 Will Staehle Image
2008 Michael Chabon The Yiddish Policemen's Union 2007 HarperCollins $26.95 Will Staehle Image
2008 Michael Chabon The Yiddish Policemen's Union 2007 HarperAudio $39.95 Will Staehle Image
2008 Michael Chabon The Yiddish Policemen's Union 2007 HarperLuxe $26.95 Will Staehle Image
2008 Michael Chabon The Yiddish Policemen's Union 2007 HarperCollins / SFBC $14.99 Will Staehle Image
2009 Neil Gaiman The Graveyard Book 2008 HarperAudio $18.99 Dave McKean Image
2009 Neil Gaiman The Graveyard Book 2008 HarperCollins $17.99 Dave McKean Image
2009 Neil Gaiman The Graveyard Book 2008 Harper Children's Audio $22.95 Dave McKean Image
2009 Neil Gaiman The Graveyard Book 2008 HarperCollins $18.89 Dave McKean Image
2009 Neil Gaiman The Graveyard Book 2008 HarperCollins / SFBC $11.99 Dave McKean Image
2010 China Miéville The City & The City 2009 Del Rey / Ballantine $26.00 FWIS Image
2010 China Miéville The City & The City 2009 Del Rey / Ballantine $11.99 UNKNOWN Image
2010 China Miéville The City & The City 2009 Del Rey / Ballantine $26.00 FWIS Image
2010 China Miéville The City & The City 2009 Del Rey / Ballantine / SFBC $14.99 FWIS Image
2010 China Miéville The City & The City 2009 Subterranean Press $75.00 Vincent Chong Image
2010 Paolo Bacigalupi The Windup Girl 2009 Night Shade Books $24.95 Raphael Lacoste Image
2010 Paolo Bacigalupi The Windup Girl 2009 Night Shade Books $6.00 Raphael Lacoste None
2010 Paolo Bacigalupi The Windup Girl 2009 Night Shade Books $15.99 UNKNOWN Image
2011 Connie Willis Blackout 2010 Spectra / Ballantine Books $11.99 UNKNOWN Image
2011 Connie Willis Blackout 2010 Spectra / Ballantine Books $26.00 Charles Brock Image
2011 Connie Willis Blackout 2010 Spectra / Ballantine Books / SFBC $14.99 Charles Brock Image
2011 Connie Willis Blackout 2010 Subterranean Press $75.00 J. K. Potter Image
2011 Connie Willis Blackout 2010 Spectra / Ballantine Books $26.00 Charles Brock Image
2011 Connie Willis Blackout 2010 Spectra / Ballantine Books $16.00 UNKNOWN Image
2011 Connie Willis Blackout 2010 Brilliance Audio $39.99 UNKNOWN Image
2011 Connie Willis Blackout 2010 Brilliance Audio $29.99 UNKNOWN Image
2011 Connie Willis All Clear 2010 Spectra / Ballantine Books $26.00 Charles Brock Image
2011 Connie Willis All Clear 2010 Spectra / Ballantine Books / SFBC $15.99 Charles Brock Image
2011 Connie Willis All Clear 2010 Spectra / Ballantine Books $11.99 UNKNOWN Image
2011 Connie Willis All Clear 2010 Brilliance Audio $39.99 UNKNOWN Image
2012 Jo Walton Among Others 2011 Tor $24.99 Kamil Vojnar Image
2012 Jo Walton Among Others 2011 Tor $9.99 Kamil Vojnar Image
2013 John Scalzi Redshirts 2012 Tor $24.99 Peter Lutjen Image
2013 John Scalzi Redshirts 2012 Tor / SFBC $14.99 Peter Lutjen Image
2013 John Scalzi Redshirts 2012 Tor $9.99 Peter Lutjen Image
2014 Ann Leckie Ancillary Justice 2013 Orbit (US) $15.00 John Harris Image
2014 Ann Leckie Ancillary Justice 2013 Orbit (US) $9.99 UNKNOWN Image
2015 Cixin Liu The Three-Body Problem 2014 Tor $25.99 Stephan Martiniere Image
2015 Cixin Liu The Three-Body Problem 2014 Tor / SFBC $26.99 Stephen Martiniere Image
2016 N. K. Jemisin The Fifth Season 2015 Orbit (US) $15.99 Lauren Panepinto Image
2016 N. K. Jemisin The Fifth Season 2015 Orbit (US) $9.99 UNKNOWN Image
2017 N. K. Jemisin The Obelisk Gate 2016 Orbit (US) $15.99 Lauren Panepinto + Arcangel Image
2017 N. K. Jemisin The Obelisk Gate 2016 Orbit (US) $9.99 UNKNOWN Image
2018 N. K. Jemisin The Stone Sky 2017 Orbit (US) $16.99 Lauren Panepinto + Arcangel Images Image
2018 N. K. Jemisin The Stone Sky 2017 Orbit (US) $11.99 Lauren Panepinto + Arcangel Images Image
2018 N. K. Jemisin The Stone Sky 2017 Orbit (US) $16.99 Lauren Panepinto + Arcangel Images Image
2019 Mary Robinette Kowal The Calculating Stars 2018 Tor $18.99 Jamie Stafford-Hill Image
2019 Mary Robinette Kowal The Calculating Stars 2018 Tor $9.99 UNKNOWN Image
Thanks, I'll let James know! Ahasuerus 22:25, 16 September 2019 (EDT)

Sciencewood - non-genre non-fiction - a second set of eyes needed

Does anyone see a reason to keep this one in the DB? It looks like a popular science book, no speculative element and not about speculative content -- which is out of scope if you are not above threshold. Or is there something I am missing about the author or the book? Thanks to anyone that would lend an eye (or 2) to that book and help determine what to do with it. Annie 18:00, 17 September 2019 (EDT)

Not seeing anything that would indicate it belongs here. The author image is from Amazon, so we won't need to remove it if the book is deleted (since this is the only entry for the person). ···日本穣 · 投稿 · Talk to Nihonjoe 18:36, 17 September 2019 (EDT)
And it had been nuked from space - both pub and title. Even if we had to delete the image manually, it is not that hard either. Thanks for verifying for me. :) For anyone interested who lands here after the deletion, this is the book in question. Annie 18:51, 17 September 2019 (EDT)

Curious records in awards table for Tiptree Award

The records in the awards table for the Tiptree have (at least) 8 "meta" records that seem to be purely for display purposes, and aren't actually works that were nominated for the award. This SQL query will show them (at least the ones I'm aware of):

   select * from awards where award_title  like '%Honor List%' or award_title like '%Long List%';

Alternatively, you can see them at these URLs:

I've not noticed these for any other award, and they only seem to exist for 2009, 2011, 2013, 2014 and 2015 in the Tiptree. (I noticed them a while ago, but it's only now that I need to deal with them for a project I'm working on that uses a local copy of the database.)

Are these a legitimate/expected way of using ISFDB? If not, could/should they be deleted?

As far as I can tell they have use award_level values - as opposed to some special value that might indicate they are meta-records - which were chosen so that they appear in a particular place on the award pages (such as the first of the three links above). However, they seem somewhat redundant functionally, as the "proper" Finalists and Honorable Mentions headings also appear on that page. Perhaps someone felt those terms were inaccurate, and created these other records to try to address that? —The preceding unsigned comment was added by ErsatzCulture (talkcontribs) .

I am not sure I am getting the question - so let me try to clarify :)
The Honorable list is an official list and we do record Long lists and so on when an award announces them - so their availability depends on the award itself. So what exactly is bothering you? Annie 19:08, 18 September 2019 (EDT)
If you look at the 45437 & 45438 links provided above, you will see that the "--- Honor List ---" and the "--- Long List ---" headings on the year page have been implemented by creating fake award records. It's a rather unorthodox attempt to add the award's actual names for these subcategories instead of the ISFDB's standard award levels. -- JLaTondre (talk) 19:18, 18 September 2019 (EDT)
(JLaTondre has basically given my response - much more succinctly - but here's what I was about to submit before getting into an edit conflict):
My question isn't with the awarded works being in the database, but that there are additional records - the ones with these headings - that have also been added, which don't exist for any other awards, or indeed for most years for the Tiptree. This makes writing code that queries the database a bit of a hassle - not impossible to deal with, but more than I'd like, especially if the offending records shouldn't have been there to start with.
Let me give an example. If I wanted to know how many finalists there were in 2018 - a year which isn't affected by this issue - I would do this database query:
   select count(1) from awards where award_type_id = 43 and award_cat_id = 523 and year(award_year) = 2018 and award_level = 90;
and get back the answer 11, which is correct. (Just for clarify: 43 and 523 are the IDs for the Tiptree and its main category respectively; 90 denotes finalist.)
If I switch the year value to 2015, and run the query, I get back 12. That's one too many, because "--- Honor List ---" is counted as one of the finalists. To get the right answer, I would have to add some logic to filter these out, but that requires foreknowledge of what these "meta-values" are, and for all I know, next year someone could enter them with different text, or as italic, and then my code will be wrong again.
Don't get me wrong - I'm certainly not asking or expecting ISFDB to change functionality just to suit my personal project, but my suspicion is that perhaps these "meta-records" weren't something that was expected when the award functionality was designed or implemented.
Can I ask a question in turn - is there any particular reason you know of why 2009, 2011, 2013, 2014 and 2015 might have these records, but no other years of the Tiptree? —The preceding unsigned comment was added by ErsatzCulture (talkcontribs) . 16:30, 18 September 2019 (EDT)
It looks like someone was wanting it to say "Honor List" and "Long List" instead of the system-generated "Finalists" and "Honorable Mentions" (respectively), even though these last two are still displayed. So, pretty much what JLaTondre wrote. I think these should be removed. ···日本穣 · 投稿 · Talk to Nihonjoe 19:35, 18 September 2019 (EDT)
(after resolving conflict) Ah, now that you pointed it out, I see it - I was loking at the lists themselves and not getting it. :) Sorry - had a slow moment here :) Isn't that similar to a question we had earlier this month about special names and what's not (wasn't it one of the Japanese awards?) - except someone went and did them that way instead of asking how? I would say that they should be removed and we need to discuss that "custom naming" thing for awards and levels.
As for why only some years - because noone added them? :) Different people add different awards at different times so... who knows - we keep adding missing information all over the place. Annie 19:37, 18 September 2019 (EDT)
I've deleted the bogus records. ···日本穣 · 投稿 · Talk to Nihonjoe 19:41, 18 September 2019 (EDT)
Thanks. —The preceding unsigned comment was added by ErsatzCulture (talkcontribs) . 16:47, 18 September 2019 (EDT)

eBook types

Hello all. Recently I re-visited this ebook pub record, to which an ASIN was added well after I created the record. Since this ASIN is for another ebook format (MOBI/AZW) compared to the original (EPUB), it started me thinking if we need/want to discriminate between different ebook formats, much like we have hc, tp, pb,... format types for paper books? Searching the internet a bit reveals that this particular pub, when bought from bol.com, is in EPUB format, whereas if it is bought from Amazon it will likely be in AZW3 (MOBI for older books I believe - not 100% sure on this one) format. So, since these are different formats, and since they generally are DRM protected and therefore not readily convertible into one another (at least not officially, that is...), I'd think it makes sense to add ebook formats to the dropdown list. Could be something like

  • ebook - EPUB
  • ebook - MOBI
  • ebook - AZW (all versions)
  • ebook - IBA (this one's Apple's, I believe)
  • ebook - other

as these are the most popular ones.
Thoughts ?
BTW, nice summary here: https://www.makeuseof.com/tag/ebook-formats-explained/
MagicUnk 09:04, 19 September 2019 (EDT)

A lot of books are available in multiple formats at the same time -- do we really want to add multiple copies to the DB? And unlike the physical books, conversions are possible very easily. I would much prefer we keep one type and either use Notes or add a new text field for format details... Just thinking aloud. Annie 10:33, 19 September 2019 (EDT)
I guess that if it would be so that electronic versions could be easily and without any restrictions and at all times be converted into each other (or be able to be read by whatever reading app/device), we could argue that the issue is moot and that for all practical intents and purposes the ebook formats can be effectively considered the 'same' (for as far as we're talking about the exact same contents of course). However, since this is not the case (not all formats can (should legally not) be converted, nor all ereaders can read all formats), I am inclined to think we should be able to make a distinction - preferably without having to clutter the notes, but if not, then the notes will have to do :).
Now, as for the how to distinguish, I see a couple of options. Adding more choices to the dropdown as listed above is just one possibility, and would be in line with what we already have for paper and even for audio formats too, albeit that these are physical formats, as opposed to electronic ones for ebooks. Adding an additional field to select the ebook (sub-)type is another, and even adding multiple additional types to a single ebook pub record (much like the possiblity to add multiple external ID's with the '+' button, or what we intend for the eagerly awaited multiple price enhancement - hint-hint :), could be a third. MagicUnk 11:23, 19 September 2019 (EDT)
I think we should handle this at the publication level as we always have. A publication is a salable product (and can and often is assigned an ISBN, UPC or other product code). Does one have to buy the item again to get another format? Then it likely is a separate publication. If not, then it is more like another part of the same product/publication (and we do not explicitly track that though a note in the pub record stating which formats a publication supports might be nice). Uzume 11:51, 22 September 2019 (EDT)
Well, that's the thing, isn't it? You cannot normally convert/are not allowed to convert between EPUB and MOBI, so you'd have to buy a new version, hence end up with two pub records... MagicUnk 18:42, 23 September 2019 (EDT)
It is quite easy to convert between the two. There are sellers who also provide multiple formats for a single purchase. This suggestions adds a lot of complexity & work for no gain. -- JLaTondre (talk) 18:50, 23 September 2019 (EDT)
I am not aware that it is legal to do so in all cases, or is it?MagicUnk 01:57, 24 September 2019 (EDT)
As long as one does not sell the converted copy I believe this is legal under fair use. Uzume 00:25, 1 October 2019 (EDT)

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).

  • Two 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 (example and 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. example.

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 (we can always add some filters on the grid page if they start looking heavy) - especially now that we show the non-common formats so it will be clear why we have multiples. What does everyone think? Annie 23:14, 19 September 2019 (EDT)

Magazine handling is a little strange. It would be easier from a data management/maintenance perspective if we put it all into one. I wonder if we could somehow use a combination of pub series and title series to help organize. --MartyD 07:39, 20 September 2019 (EDT)
I believe we still support super series, e.g. you can see Astounding / Analog (1937-1971) and Astounding/Analog (UK), however there is also Astounding/Analog which merges the two (albeit in this case with some other stuff but methinks you get the idea). Also in this case the UK reprints are not exactly exposing a different format so much but a super series could be made for both of Galaxy's Edge and Galaxy's Edge (digital edition) and then one would be able to view a merged issue grid if one wanted to. For something like Journey Planet, one would have to split the editorial records and make another series and then super series the both. Uzume 11:23, 22 September 2019 (EDT)
Since Marty brought it up again, I always thought magazines should be defined/handled as pub series instead of the hackish way we do it now using their editorial records (which I have never suggested should go away; for some reason whenever I mention magazines as pub series that is the first thing people seem to think I am trying to get rid of). I realize we have many such records and it would be a large effort to create pub series for all the magazines/fanzines, etc. but it does solve the complexity of our current issue grid (and having an issue grid view for other non-magazine pub series might be useful too; I wonder if we have an FR on that) as well as allowing us to merge editorial records for different formats/reprints/etc. but still allow one to record and present them each separately. I believe our software does not currently support super pub series (though that might also be a useful addition) Uzume 11:23, 22 September 2019 (EDT)

Biographical warnings for audio books

I think that awhile back we suspended showing bibliographic warnings for missing ISBN/Catalog ID when the format of the book is ebook. Can we extend that to the "digital audio download" type as well? Example where we have both types and just one warning: Yarn. Or is there a reason to always have it (because these will (almost) never have ISBNs and catalog numbers)? Thanks! Annie 04:02, 21 September 2019 (EDT)

I don't think it was a conscious decision. We (or at least I) didn't realize that "digital audio download" books typically didn't have ISBNs. Ahasuerus 09:12, 21 September 2019 (EDT)
I think it was a "let's try to clean this thing" kind of thing and as we did not have that many audio books, noone thought of it.:)
How about prices and webzines? The warning is there even though the vast majority of webzines do not have prices unless we really like typing 0.00. And since we opened the doors for them, we have more than we used to. Annie 11:51, 21 September 2019 (EDT)
FR 1306, "Suppress bibliographic warnings for digital audio downloads", has been created. Ahasuerus 10:55, 3 October 2019 (EDT)
FR 1306 has been implemented. Ahasuerus 15:36, 4 October 2019 (EDT)
Any objections to suppressing bibliographic warnings for webzine issues without a price? Ahasuerus 10:55, 3 October 2019 (EDT)
Hearing no objection, FR 1308 has been created. Ahasuerus 21:32, 10 October 2019 (EDT)
FR 1308 has been implemented. Ahasuerus 19:16, 12 October 2019 (EDT)

Question about the Twilight Zone Universe lists

Is there a reason for not including Richard Matheson's Twilight Zone Scripts volumes in the Twilight Zone Universe lists? —The preceding unsigned comment was added by Klepsis (talkcontribs) .

Good catch! I have put them in a new series, Twilight Zone Scripts (Richard Matheson), and turned it into a sub-series of Twilight Zone Universe. I've also disambiguated the name of Twilight Zone Scripts (Rod Serling) to avoid confusion. Thanks! Ahasuerus 18:46, 3 October 2019 (EDT)

Templates for incomplete contents

Can we create a template for incomplete contents to be used in publication Notes ({{Incomplete}} for example) that shows "The contents are incomplete" (or anything else we want for it to say)? We have a very good way to find magazines and collections and anthologies with no fiction content but once at least one story is added, the title drops from the report (and sometimes a non-fiction magazine that is ignored from the report still needs its no-fiction contents to be finished. And every editor seems to use their own string: "Content from Place; possibly incomplete.", "Incomplete Contents", "contents incomplete", "contents possibly incomplete" and so on. Trying to find all of them so someone can update them is... hard. Annie 16:30, 3 October 2019 (EDT)

Seems like a good idea. Can anyone think of a reason not to create {{Incomplete}}? Ahasuerus 11:30, 4 October 2019 (EDT)
FR 1309, "Create an 'Incomplete' template", has been created. However, before I do implement it, let's make sure that we are all on the same page. The use of this template is supposed to be limited to pubs missing eligible Contents items; it will not be used for pubs which exclude ineligible (typically non-genre) items on purpose, right? Ahasuerus 21:38, 10 October 2019 (EDT)
Yeah, that's the idea. Christian Stonecreek 02:49, 11 October 2019 (EDT)
Yep. Annie 03:12, 11 October 2019 (EDT)
The FR has been updated. Thanks! Ahasuerus 15:16, 12 October 2019 (EDT)

Leading and Trailing spaces in External IDs

Can we modify the javascript check when submitting a publication to first trim() the data in the field and then check if it contains any of the characters we do not want (and then trim again on the back end before saving so we do not save them or pass back the trimmed value)? If I leave an extra space at the end of a title, ISBN or any other field, it just ignores it and cleans it up before saving. The External ID field makes me go and remove it before I can submit... :) Thanks! Annie 20:29, 3 October 2019 (EDT)

Makes sense. FR 1307, "Strip leading and trailing spaces in External IDs", has been created. Ahasuerus 12:12, 4 October 2019 (EDT)

New User

Greetings from Algonquin

I am a very new user to your App (isfdb.org).

What is the purpose of isfdb.org?

With Best Regards,

Jed Dowd (Algonquin) Mypoustinia@msn.com 3 October 2019 at 20:33 CDT —The preceding unsigned comment was added by Algonquin (talkcontribs) .

Welcome to the Database. We are a bibliography site - trying to cover the field of Speculative fiction and list all editions of all books published in the field (and it is a work in progress...). Look around - if you want you can just browse and use the data or you can decide to help - if so, here is the main wiki page with a lot of useful links on how to do things and what you can do and so on :) And you can always ask here.
From our main page: "The ISFDB is a community effort to catalog works of science fiction, fantasy, and horror. It links together various types of bibliographic data: author bibliographies, publication bibliographies, award listings, magazine content listings, anthology and collection content listings, and forthcoming books.".
How did you find us and what were you looking for? :) Annie 22:02, 3 October 2019 (EDT)

Add the rest of the Amazons where they are missing

Can we add the rest of the Amazons to the list of available sites for links? We have only 6 of them now (including missing one of the English language ones...)- and I keep needing some of the rest and having the direct link there will be very useful...

And just in case the list is stored separately, I also want them on the moderator screen so I can click on them for books with ISBNs while trying to research a submission.

And while we are at it, we are also missing two Amazons on the ASIN list - Turkey and UAE:) Annie 00:32, 4 October 2019 (EDT)

Sure, we can do that. Our list of supported Amazon stores hasn't been adjusted in years. A lot has changed in the last decade. Here are the stores that we currently support:
  • Amazon CA
  • Amazon DE
  • Amazon FR
  • Amazon JP
  • Amazon UK
  • Amazon US
Here are the Amazon stores that I think we could add:
Any others? Ahasuerus 11:59, 4 October 2019 (EDT)
You should have 16 - so one is missing: Netherlands. And it is one I need a lot - we have quite a lot of Dutch speaking editors these days:) Annie 12:07, 4 October 2019 (EDT)
Noted, thanks. Ahasuerus 12:15, 4 October 2019 (EDT)

(unindent) One problem that I think we are going to have is "screen real estate". Once we link all 16 Amazon stores, the "Other Sites" drop-down list on the Publication display page is going to become unwieldy. Perhaps we could move the Amazon links (all 16 of them) to another, adjacent, drop-down list? I guess we could call it something clever like "Amazon Links". Ahasuerus 22:39, 10 October 2019 (EDT)

Yes, this seems to be a better solution. Christian Stonecreek 02:48, 11 October 2019 (EDT)
Thanks. FR 1310, "Link to all Amazon stores", has been created. Ahasuerus 15:15, 12 October 2019 (EDT)

Series content counts

How easy would it be to have the system do a count every day (or every week) of the number of unique titles in a series, then list those numbers at the top of the series page? Maybe even list the number of short fiction, collections, omnibuses, non-fiction, etc., too? This might be useful information on author/artist pages, too. ···日本穣 · 投稿 · Talk to Nihonjoe 13:27, 4 October 2019 (EDT)

I assume you mean mostly for series that are not numbered, right? I like the idea. :) Annie 13:32, 4 October 2019 (EDT)
It's more for series that are ginormous (like Star Wars or Star Trek), that have a bunch of different series within the series, as well as many collections, omnibuses, short fiction, and so on. Statistics are harder to manually do in those cases. ···日本穣 · 投稿 · Talk to Nihonjoe 13:58, 4 October 2019 (EDT)
I like the idea of displaying counts. Not just for series, but for the Contents sections of publication pages as well. However, I don't think we want to calculate them once a day/week because it would create discrepancies. Doing it on the fly shouldn't really affect performance.
The only problem that I can see is the way the software currently displays embedded series. It would likely require a medium amount of work to get everything working properly. Ahasuerus 15:03, 4 October 2019 (EDT)
I imagine there's a series table in the database, listing the title and parent for each series. If a new column (or columns, depending on how granular you want to do things) was added to each series for the count, then it would be a run through to do all the counts, then another that adds up counts for any subseries. The last one would repeat until all the sub-sub-sub-sub series are totaled. Something like that? ···日本穣 · 投稿 · Talk to Nihonjoe 15:15, 4 October 2019 (EDT)
True, there is a "series" table in the database. It contains each series':
  • title
  • parent series
  • relative position within its parent series
  • note
That said, adding a new column and updating it on a daily/weekly basis would result in series counts being potentially out of sync with what is actually displayed for up to 24/168 hours. I believe that would be Very Bad (tm).
Now, the problem with doing these calculations on the fly is that the software which displays series data is invoked recursively for embedded sub-series. Every time it is called, it doesn't know much about the parent series that invoked it; it just displays all titles in the series and returns to its parent, which then calls it again to display the next sub-series, etc. The software would need to be modified to keep track of the total number of titles that it has displayed for the whole series tree. In addition, it wouldn't have the totals until the last sub-series has been displayed, so it would have to be displayed at the bottom of the page -- unless we redesigned the software to accumulate all that display data first and display it second. To complicate matters, the same series display code is used by Series pages as well as by Author Bibliography pages. They display co-authors differently.
In other words, it's probably doable, but would require a certain amount of tinkering. Ahasuerus 15:51, 4 October 2019 (EDT)
How about a solution similar to how we solved the counts number in Advanced Search? Instead of showing it every time, add a button/link which calculates it and shows it on the fly when pressed? This way an editor can find the number easily but we do not calculate it for series that do not need it and we do not change all the underlying logic of the series pages. Annie 16:00, 4 October 2019 (EDT)
Another possibility: Have the count on each series update whenever a new item is added to the series? That would keep it current, and be a logical place for it to increment the count. Then, when it's incremented the count, have a subroutine that checks to see if the series has a parent. If so, then have it increment the parent's total count. Do that until there are no more parents. There would have to be something in place to prevent simultaneous incrementing (in case two or more different entries were updated/approved simultaneously), so it would do one, and then the other. When initially implemented, a single-run script could create the initial counts for each series, and then the updating could be done as I described above. ···日本穣 · 投稿 · Talk to Nihonjoe 16:03, 4 October 2019 (EDT)
This strikes me as a cool idea, but the developer part of my brain wonders about all the nasty edge cases. e.g. would it make sense to show The Night's Dawn *Trilogy* as comprising 9 novels - the 3 UK (?) volumes plus the 6 volumes from the "Night's Dawn Trilogy (paperback)" subseries, which are (AFAIK) the same content, just split into 2 smaller books? From my limited understanding of the database, I don't see anything that indicates the latter are a "variant series", other than text notes in the former stating that they were split into 2 volumes for US publication. ErsatzCulture 17:40, 4 October 2019 (EDT)
And you also have the moving of series under new parents (or removing them from parents) which will cascade calculations at update time as both the new and the old parent and the current series totals (plus all additional parents) will need to be recalculated... Annie 17:49, 4 October 2019 (EDT)
True. As a general observation, database designs that required keeping running totals of things were popular in the 1960s and 1970s, back when data was mostly stored on tape. They became less popular once cheap and reliable disk storage became available. And a good thing too because they were a pain to maintain. Ahasuerus 19:57, 4 October 2019 (EDT)

New cleanup report - Publication Series Names That May Need Disambiguation

A new cleanup report, "Publication Series Names That May Need Disambiguation", has been coded and deployed. The data will become available overnight. I expect approximately 75 records to be flagged. Ahasuerus 21:57, 4 October 2019 (EDT)

Displaying title tags on the Advanced Search Results page

Last year we had the following request posted on the Community Portal (FR 1166):

If you use Advanced Title Search and one or more of the results have too many tags, the tags column squishes the rest of the fields and takes over most of the screen. Here is an example.
Can we add a new user preference (similar to the "Do not display bibliographic warnings on Title pages") that controls if a user sees the tags in advanced search at all? This way if someone really does not care about the tags can stop them from cluttering the page.
Alternatively, we could set a hard width for the column using a percentage. ("Specific pixels width" wouldn't work for phones.)

Earlier today User:ErsatzCulture proposed the following solution:

  • If the user included a tag value in their search criteria, show all tags (on the logic that this is something they're definitely interested in, and we don't want to risk hiding the tag they searched on)
  • If they didn't include a tag in the search criteria, then we limit the number of tags - currently 5, which seems to limit to no more than 2 lines of tags on a 1280px wide screen.
Example screengrabs:

NoTagCriteria.png

WithTagCriteria.png


I rather like this approach. What do other editors think? Ahasuerus 10:35, 7 October 2019 (EDT)

I like the approach but I still think we need to do some restriction on the field and/or the ability not to see tags at all. I do most of my work from small screens - and having 5 tags is already making my screen too hard to see what I need. And the things get worse if one of the tags is extra long. Annie 12:11, 7 October 2019 (EDT)
Seems a bit counter-intuitive. If I search for titles with a particular tag, it's likely I know everything I need to about tags for my selection. And I'm assuming my tag is there for everything displayed. Unless you get into OR conditions ... ../Doug H 14:03, 7 October 2019 (EDT)
I think you're correct on a functional level, but I think human beings generally need reassurance that the results they've got back match what they expected to get. Compare this to when you do a search for something on Google or on a Kindle device, the displayed results highlight the searched keywords in bold or inverse video to show you the match, and to provide context etc.
My thinking for displaying all tags if the user searched for tags, is that searching on tags expressly signals an interest in tagging from the user, so it seems reasonable to show detail in that area.
Re. user controllable showing/hiding of columns, this would obviously be a preferable solution, but it would involve more work. Also, it feels like something which doesn't fit the current preference model, but rather something which should be configurable on the fly in the results page itself, probably with the prefs being stored on a per-device level. (If anyone's switching between using the site on a phone and an HD/4k screen on a regular basis, it's unlikely they'd want the same display settings in both environments.)
All of this is doable, it's just working out the tradeoffs between user needs and pain (and obv. the needs etc of casual users vs contributors vs mods aren't necessarily the same), developer time/interest, etc, etc.... ErsatzCulture 14:30, 7 October 2019 (EDT)
after thinking some more on that. A bit of a background. I proposed that FR awhile ago because the current results screen makes it very hard for me to do a lot of the things I do on a daily basis. This solution won’t solve the problem so if you want to implement it, go ahead and do that. Then I will ask for another FR that actually solves the problem I am having. If you have a big enough screen, the tags are not that big of a trouble - we do not have that many titles with more than 5 tags (can someone check how many)? And the problem is not just how many lines they take but also how much of the screen they take - they squeeze (squish in my original writing above) the columns I am looking for on a small screen taking more than half the screen. And let’s not ignore the fact that a lot of the casual browsers will be using touchscreens and other small screen devices - and making that page work only when you are at home and have your nice big screen is a little behind the times. :) Annie 15:09, 7 October 2019 (EDT)
Not directly related, but it might be good to start planning for a mobile version of the site that presents the options better for a smaller screen. Maybe we should make a page to start discussing that. It would basically present information based on the reported browser. ···日本穣 · 投稿 · Talk to Nihonjoe 16:04, 7 October 2019 (EDT)
It is not just mobile though - I have one of the small Chromebooks (11.6") which is perfect for what I need it for - but the screen is small :) And when a page is optimized for regularly sized screen, it does need to compensate somewhere :) But yeah - we probably should - although some of the pages will need too much of a redesign... Annie 21:30, 7 October 2019 (EDT)
If we spend the time hammering out a good design, it will make making changes more easy in the future. I've made this page to help facilitate discussions toward that end. ···日本穣 · 投稿 · Talk to Nihonjoe 15:17, 11 October 2019 (EDT)

Signing notes

Is there a simple way to sign and date notes (Title and Publication in particular) that is invisible on the display but easily seen and edited in the Editing window? ../Doug H 11:25, 10 October 2019 (EDT)

Nope. Which is why I add a very visible date when that is relevant.
Technically you can use {{BREAK}} which will send it to a separate screen so it will be there if someone wants to see it but not there on the main screen. Annie 11:51, 10 October 2019 (EDT)
So nothing like html comments <! > or null tags ../Doug H 12:35, 10 October 2019 (EDT)
Nope. If you use them, they will get flagged as not allowed HTML and cleaned up overnight if the accepting moderator does not catch them on submit and clean them there and then. If you think they will be useful, you can always open a discussion about allowing them but... I am not a fan of hidden text - way too easy to miss and way too easy to be exploited for someone's advertisement purposes or other mischief. And if we want to keep track of the notes, we probably should built it into the system as opposed to asking an editor to add the data. Annie 13:31, 10 October 2019 (EDT)
Wouldn't it be a good thing we'd always sign & date the notes? I'm working at a pharma company, and there it's mandatory to always sign & date every single change you make to a record ... MagicUnk 09:49, 11 October 2019 (EDT)
Only if we have a system that suppresses that from the everyday screens. You really do not want 20 lines of history for every line of a note.  :) Annie 13:00, 11 October 2019 (EDT)
Well, there is FR 1238, "Create an Edit History page for publications", which would create snapshots of verified publication records before they are changed. It would help with a lot of different issues. Ahasuerus 14:56, 12 October 2019 (EDT)
Won't help with Title records though. Implementing a search in the submissions list will help to at least find the history of a title (if not changed) though... Annie 15:22, 12 October 2019 (EDT)

'Incomplete' template created

"Incomplete", a new template, has been created as per FR 1309. At this time it is displayed as "Contents incomplete."

Checking the database, I see that we have:

  • 508 notes with the words "content[s] incomplete"
  • 31 notes with the words "incomplete content[s]"
  • 422 notes with the words "partial content[s]"

Should we create a cleanup report to review/update them? I assume the report will need to support the "ignore" functionality. Ahasuerus 20:02, 12 October 2019 (EDT)

I can pick these off with search but a report may be worth it for future additions. There is one more pattern “content[s] [random words] incomplete/not complete”. Annie 20:17, 12 October 2019 (EDT)
That's a good point. There are 831 matches, including 508 previously listed "content[s] incomplete" matches. Ahasuerus 20:27, 12 October 2019 (EDT)
I wonder if a wider net may be even better: If it has the word content[s] and "incomplete|partial|not complete", throw it on the report so we can sort it out and decide if it can be filled in (best solution), needs the template or is one of the non-genre stories type where it will stay like that. And then of course we will need a report for the ones that have the template - similar to the reports for the anthologies and magazines with no contents one day. Annie 20:59, 12 October 2019 (EDT)
A cleanup report is a very good idea. I've come across several records like this in the past, where it seems that the editor put the "incomplete" info into the pub's note but then forgot about it.
In addition to the already mentioned words, there are a few more words to consider which will find pubs like this and this (but also one or the other false positive, therefore an "ignore" option in the report is a good idea):
  • "%to be entered"
  • "%more%contents%added%"
  • "%not entered yet%"
  • "%have to be added%"
Jens Hitspacebar 07:47, 13 October 2019 (EDT)
Very good points. I have run a bunch of database searches to get a better idea of how many false positives some of the proposed search strings are likely to generate and created FR 1311, "Cleanup report to look for pubs with incomplete contents". Ahasuerus 12:40, 13 October 2019 (EDT)
Some other thing to consider is to ignore pubs that already have the 'incomplete' template in the notes, see eg this one. MagicUnk 14:27, 13 October 2019 (EDT)
That’s a given - we have quite a lot of reports like that already so the exclusion does not need mentioning. Annie 14:38, 13 October 2019 (EDT)
Yup, notes which include the string "{{Incomplete}}" will be skipped with extreme prejudice! Ahasuerus 16:08, 13 October 2019 (EDT)

(unindent) The new cleanup report has been deployed; the data will become available in about 6 hours. I expect that we will need to review around 1,860 pubs.

I have also created FR 1312, "Cleanup report to find pubs which use the 'Incomplete' template". Ahasuerus 19:53, 13 October 2019 (EDT)

I added information about the new template to Help:Using_Templates_and_HTML_in_Note_Fields. Please correct if I got something wrong there. Jens Hitspacebar 15:03, 14 October 2019 (EDT)
Thanks! I knew I was forgetting something... Ahasuerus 16:17, 14 October 2019 (EDT)

The listing for this non-genre publication is intentionally incomplete, only SF content is listed

We have 110 publications with this specific wording and I kinda like it a lot. How about a template ("non-genre incomplete" for example) for this? It will be useful in two ways:

  • Someone finding the publication will know why it is half-empty.
  • An approving moderator will be extra careful when approving more content.

Plus it will take less typing than the full message. :) Thoughts? Annie 03:46, 16 October 2019 (EDT)

I like this idea. ···日本穣 · 投稿 · Talk to Nihonjoe 13:06, 16 October 2019 (EDT)
Should it be "only SF content is listed" or "only ISFDB relevant works listed" (or similar wording)? That would handle the non-genre author above the the threshold issue for mixed genre anthologies. The "ISFDB relevant" could be then linked to the Rules of Acquisition policy page. -- JLaTondre (talk) 18:11, 16 October 2019 (EDT)
Probably. That's part of the beauty in using a template - we can change what it says when we want to without running yet another cleanup project. And I was thinking about adding a link as well - this was just the best way I found already recorded :) Annie 18:17, 16 October 2019 (EDT)
Like this idea. I've entered a number of "content only includes genre items" in the past, and a template would be welcome. Bob 18:44, 16 October 2019 (EDT)
I like the idea of a template, but I am still trying to come up with a name that would cover all the bases. The only thing that I am more or less sure about it that I like "eligible [for inclusion]" more than "relevant". Ahasuerus 19:18, 16 October 2019 (EDT)
Yes, "only ISFDB eligible works listed" would be better. -- JLaTondre (talk) 19:20, 16 October 2019 (EDT)
I like "ISFDB eligible" as wording of the text. How about "policy incomplete" or "DB incomplete" or something along that line for a name. It needs to be short enough and clear enough if we want adoption without too many misspellings. Annie 19:38, 16 October 2019 (EDT)
Another option would be "Only Eligible". Ahasuerus 19:52, 16 October 2019 (EDT)
I like that! Annie 20:20, 16 October 2019 (EDT)
I would prefer a litte more self-explanatory: a little longer, but what about "only eligible content"? MagicUnk 02:25, 19 October 2019 (EDT)
Well, Our template names tend to be short and/or abbreviated: "Tr", "MultiS", "MultiPubS", etc. Something like "OnlyEligible" would be more in line with the rest of the menagerie. Ahasuerus 12:48, 19 October 2019 (EDT)

Series and international names

Let's start talking about that again. There are two aspects of this:

  • Collect the information
  • Show it in the relevant places (in a book in a language we have the book in).

The second will require development but the first one is a pure data gathering operation for now. A few editors (me including) had taken to adding "Series name in Language: Name" in the notes of the series. Which kinda works but it will be better if we can formalize a bit. I know that two-parameter templates are not workable and creating a template for each language we support will be an overkill so... should we just formalize our practice in the Series Data help page for now? While we figure problem #2 above at least. Annie 12:57, 18 October 2019 (EDT)

Contents section - sorting

As per FR 1315, the behavior of the Contents section of Publication display pages has been changed. In the past, titles without page numbers were displayed in the order of internal database IDs, which are meaningless to users. They are now sorted alphabetically, e.g. see this publication. Ahasuerus 17:34, 20 October 2019 (EDT)

THE CHANGE HAS BEEN TEMPORARILY REVERTED -- see below for details. Ahasuerus 19:34, 20 October 2019 (EDT)
And this means that most of our non-paged collections and anthologies are now messed up - people do not consistently use | because if you are adding all new titles or importing from an existing one, the order was as you add them - and it seems like you do not need the |. It is a good change but we probably now need a report to find all collections and anthologies with no page numbers. Annie 18:00, 20 October 2019 (EDT)
Oh... I didn't think of that. How much of a problem do you expect it to cause? If it's significant, I can change the sorting algorithm back to what it was 2 hours ago until we add "|" values to all container pubs. Ahasuerus 18:12, 20 October 2019 (EDT)
Someone needs to run the queries but based on my own practices and what I had moderated, not negligible. The ID that the contents was ordered based on was not the title ID but the "line ID" - probably from the table keeping the contents. So as long as you added/imported in the order you wanted them in, they never changed no matter what title get merged where. Had it been the title ID, we would have seen the problem on the first merge and the usage of | would have been a lot more prevalent :) Classic case of using an unintended side effect to the full if its potential - while it makes sense for the order to be alphabetical, we need to take care of the works that relied on the old order - and in some cases, we may not have the information anywhere else besides that old order.
And I suspect we have also novels caught into that (order of illustrations or "Afterword" titles that will now bubble above the novel), a lot of the omnibuses and e-magazines as well.
So my preference will be to revert, create the report (any container with more than 1 non-coverart title and no pages numbers) and see what the actual damage is, clear up the ones that will get caught into this, add a warning on the addPub/clonePub/editPub that the order will be ignored and the editors need to use |) and then then implement the change. Annie 18:47, 20 October 2019 (EDT)
OK, the change has been reverted and the FR has been reopened. I'll add your comments to the FR and we'll see where we go from here. Thanks! Ahasuerus 19:34, 20 October 2019 (EDT)
I'm wondering why sorting contents alphabetically would be useful? In my mind, contents should never be sorted. Rather, use of | should be encouraged. Just my 2 centsMagicUnk 00:51, 21 October 2019 (EDT)
We do need a default - there are a lot of cases (older books and new small press anthologies and collections for example) where you can figure out the contents from reviews and publisher advertisements but not the order of the works. In that case, using | will be misleading. So as much as it should not be sorted, we do need to have a default sort - being it IDs or alphabetical. I guess alphabetical is an easy way to make it clear we do not know the order - and make different copies of the same collection look the same. :) Annie 01:27, 21 October 2019 (EDT)
True, using "|" can be misleading in cases. So, to be honest, the more reason I would leave it as-is (ie sorting on ID). This is also the behavior people will expect: "I'm seeing the contents in the order I've entered it". To me, there's no need to start fiddling around with other sorting approaches. I've never found this behavior problematic. Editors know that when they have/want to change the default sorting order, they'll have to use the '|' symbol. If needed/desired, we can clarify in the rules that sorting order is always in the order that the contents was entered - unless - "|" is used. MagicUnk 13:55, 21 October 2019 (EDT)
Someone did - thus the FR and the implementation. Annie 14:16, 21 October 2019 (EDT)
The FR was created based on recent feedback provided by Dave Langford, one of the SFE3 administrators. He noticed that the ordering of the Contents section of this pub was neither alphabetical nor chronological and didn't reflect the actual order of stories in the book. After I explained the current display logic to him, he suggested that it may be better to display unordered stories alphabetically. Ahasuerus 11:33, 22 October 2019 (EDT)
It does make some sense - we do need a default order and alphabetical makes sense more than anything (chances are that we do not have chronological order for most anthologies). We just need to take care of the ones that do rely on the current order - for every collection that is in shambles like this one above, we probably have 5 that look as if they are ordered even if they are not. Doug below made a very good point also - can we have a novel (and non-fiction -- these are the only containers that are also titles that need numbering) always appear with a |1 for example so people can order around it if needed (and not always need an edit if they have afterword and other titles in the work. If the novel needs a page number, they need an edit anyway but if it does not (e-book), why not make it easy)? :) Annie 11:45, 22 October 2019 (EDT)
I personally prefer the way as it is now -- despite it being meaningless for a user. But I can live with either. And don't forget that there is a huge amount of users that just use the DB -- you as the person that enters the book understand the order, someone finding it later does not (or even worse - we have collections which are in different order when they are not). What we do need is to start using | more consistently and clean up the ones that do not (and where we can find a source to confirm) - even if we never re-deploy the alphabetical order. Just on general principle.  :) Annie 14:16, 21 October 2019 (EDT)
As a logical exercise in understanding and explaining, how would you choose to pre-populate the page field for publications of the various types? ../Doug H 08:17, 21 October 2019 (EDT)


Various types? Of what? Annie 13:14, 21 October 2019 (EDT)
When ADDING new data, NOVELS have fields for Additional Regular Titles and no spot for the automatically created content title that matches the TITLE's title, and hence no way to enter page number using |. All other data types (ANTHOLOGY, CHAPBOOK, etc) leave it to the user to fill in every contained title along with the page number. IF we were to prefill the page field, would we put in "| n" where n is the line number? or go by 10s to allow someone to put values in between? What number goes in the generated NOVEL title field so people can place interior art and forewords ahead and excerpts and afterwords after? Before we go converting the old stuff, just trying to picture how you'd like it to work in the new approach. ../Doug H 14:50, 21 October 2019 (EDT)
No number goes in front of a novel now - you need to do a post-approval edit to add the page number (being it | or not). Which is part of the point - if you add afterwords during the creation, it always goes after the novel (ID creations and all that). If you need an Introduction, you always need to edit after that to sort out the order. :) Annie 15:34, 21 October 2019 (EDT)
PS: And there is no new approach really here - the | is an old approach. The sorting was briefly changed, I complained that this messes up our current pubs, it got pulled out. :) Now people need to edit a novel post approval only if they want to add a page number or something before the novel; if we change the order, it will mean they will need to always edit for afterwords as well. Annie 16:59, 21 October 2019 (EDT)

(unindent) One thing to keep in mind is that the way we currently display unordered titles is not really enforced by the software. If you repeatedly use Edit Pub/Clone Pub/Title Remove/etc on a pub, it's possible that the ordering may change. There is nothing in the software that makes sure that "the order in which the titles were originally entered in the Contents section" is preserved. Ahasuerus 11:42, 22 October 2019 (EDT)

Thus my "it seems like" above. But the lines for the titles are created in the order they get added in the list, the clone grabs them in the same order as well so even if there is no real enforcement, there is a de-facto one because the IDs get created linearly and you cannot insert something between two other titles (without using page numbers). It is just a side effect, being used to the full of its potential. I suspect that there are corner usecases where this does not hold but for the most part, things stay where you put them. Annie 11:52, 22 October 2019 (EDT)
I wonder if it might be good to have the system automatically add the pipe sorting in the order contents are entered if they are not added by the submitter? ···日本穣 · 投稿 · Talk to Nihonjoe 16:44, 22 October 2019 (EDT)
It wouldn't be hard to implement, but consider the following scenario. An editor is using a secondary bibliography as his source. The source lists the stories alphabetically and that's how the editor enters them. There is no implied ordering, but then the system adds "|1", "|2", etc automatically. The reviewing moderator approves the submission because it looks fine. Post-approval, we end up with a publication record which implies that we know the order of the stories even though we actually don't. That would be rather misleading, I would think.
I suppose we could approach this issue from the opposite direction: have the system display "|1", "|2", etc as the value of the Page field by default. It would then be up to the editor to change or delete the page numbers as appropriate. I am not sure that it would be an improvement, though, because some editors would likely forget to change the default values. Ahasuerus 16:11, 23 October 2019 (EDT)

ISFDB downtime -- 2019-10-21, 10:30am server time

The ISFDB server will be down for maintenance between 10:30am and 11am (server time) today. The downtime will start at 10:30am US Eastern, 7:30am US Pacific, 3:30pm UK time, 4:30pm Western European time. Both the database and the Wiki will be unavailable. Ahasuerus 09:57, 21 October 2019 (EDT)

And we are back, 14 minutes ahead of schedule! Ahasuerus 10:47, 21 October 2019 (EDT)

"Other Sites" split

As per FR 1310, the "Other Sites" drop-down list has been split into two. The first one is called "Amazon Links" and links up to 6 (soon to be expanded to 16) Amazon stores. The second one is called "Other Links" and links to the other third party sites that we support. Ahasuerus 16:01, 23 October 2019 (EDT)

The rest of the FR has been implemented. All ISBNs and ASINs should link to the same 16 Amazon stores now. Unless you change the default behavior under My Web Sites, of course. Ahasuerus 14:41, 24 October 2019 (EDT)

Display changes requested by Amazon

As many of you know, the ISFDB project participates in the Amazon "Associate" program. What this means is that:

  • Amazon gives us programmatic access to its internal database (aka "the Amazon API")
  • when we link to Amazon.com or Amazon UK, we embed an Amazon-issued affiliate ID in the URL
  • when a user follows an Amazon link with our ID embedded and buys a book, we get a few cents per book

The money that we get is typically in the $5-$15/month range and goes to partially offset server costs. In the grand scheme of things it's inconsequential and we could easily live without it. However, having programmatic access to the Amazon database is a big deal since it enables Fixer to create automatic submissions. They make it much easier to keep up with (at least English-language) new books. If we stop embedding ISFDB IDs in Amazon URLs, we will stop making money for Amazon and they will revoke our access to their database.

The latest update to the Amazon "Associate" agreement and the latest Federal Trade Commission (FTC) guidelines require Amazon Associates to disclose that they make money from Amazon links. Here is the specific language that I and, reportedly, many other participants, received from Amazon a few days ago:

  • ... you must include a legally compliant disclosure with your links ... A clear disclosure could be as simple as "(paid link)", "#ad" or "#CommissionsEarned" ... It should be placed near any affiliate link ...
  • ... the following statement clearly and conspicuously appears on your Site: "As an Amazon Associate I earn from qualifying purchases."

I am not thrilled with these requirements because implementing them will make us look more like a referring service and less like a bibliographic site. At the same time I expect that the advantage of having programmatic access to Amazon's data outweighs the disadvantages.

My current thinking is that we could add "As an Amazon Associate ISFDB earns from qualifying purchases -- see the ISFDB FAQ" to the bottom of Publication pages, right under "ISFDB Engine - Version 4.00 (04/24/06)".

For link-level disclosures there are two areas of the Publication page that are affected: the drop-down list under the recently renamed "Amazon Links" and ASIN external IDs. (Note that only Amazon.com and Amazon UK links are affected at this time.) We could display something like "affiliate link" next to Amazon.com and Amazon UK links. The FTC guidelines seem to say that "affiliate link" might not be "adequate" "by itself", but it's open to interpretation. I'd rather wait and see what happens than use "(paid link)" or "#ad", which are misleading. "#CommissionsEarned" may be a fall-back position if "affiliate link" turns out to be insufficient.

So, what do you think? Ahasuerus 16:00, 24 October 2019 (EDT)

Are the covers/images counted as links under this? And if we lose the affiliate, is our permission to use them change as well (I know we do not want to lose it but just making sure we are not missing something in case you do)? Annie 16:20, 24 October 2019 (EDT)
I don't think the covers/images count because those take you directly to the image, which has no obvious way to get to the product from there. ···日本穣 · 投稿 · Talk to Nihonjoe 18:27, 24 October 2019 (EDT)
Probably not for that link disclosure thing but I am not sure if our permission to use the images and link to them directly is tied to the associate program or not. Thus me asking :) Annie 18:47, 24 October 2019 (EDT)
I am afraid I am not really sure what the current Amazon policy re: deep-linking to their images is. Ahasuerus 19:01, 24 October 2019 (EDT)

(unindent) Hearing no objection, so ordered -- FR 1322 "Display changes requested by Amazon" has been created. Ahasuerus 16:48, 21 November 2019 (EST)

New cleanup report -- Mismatched Template Braces

As per FR 1313, a new cleanup report, "Mismatched Template Braces", has been deployed. The data will become available in approximately 5 hours. I estimate that it will find 55 records with problematic notes. Ahasuerus 20:16, 24 October 2019 (EDT)

Most were Dutch and German titles. Probably a lot of copy-paste errors. Amazing it was only 55 :) All gone now. --Willem 03:42, 25 October 2019 (EDT)
Thanks! Ahasuerus 09:39, 25 October 2019 (EDT)
As for why only 55 - these were not that hard to find with Advanced search so some cleanup had been going on ad-hoc ;) Annie 16:45, 25 October 2019 (EDT)

New cleanup report to find references to non-existent templates in Notes/Synopses

As per FR 1314, a new cleanup report, "References to Non-Existent Templates", has been created and deployed. The data will become available around 1:20am server time. I expect it to find 4 records with references to non-existent templates in Notes. Ahasuerus 15:59, 25 October 2019 (EDT)

Advanced Publication Search - Primary Verification Date added

As per FR 1316, "Primary Verification Date" has been added to the list of supported Advanced Publication Search selection criteria. Ahasuerus 19:00, 25 October 2019 (EDT)

Leading and trailing spaces in External IDs

As per FR 1307, the software has been changed to silently strip leading and trailing spaces in External ID values. You may need to do a full page reload (Control-F5 under most browsers) for the new functionality to take effect. Please note that embedded spaces are still disallowed. If you run into any issues, please let me know. Ahasuerus 19:49, 25 October 2019 (EDT)

You are on a roll today :) Thanks for getting this one fixed :) Annie 20:22, 25 October 2019 (EDT)
Sure thing. It helps that I no longer have to spend most of my time on Fixer. It also helps that I have been feeling better lately (knock on wood.) Ahasuerus 11:55, 26 October 2019 (EDT)

Top Voted list changes

As per FR 1289, "Enhance the Top Voted list", the "top voted" section of the "ISFDB Statistics and Top Lists" Web page has been changed as follows:

  • "Top 100 Novels as Voted by ISFDB Users" has been changed to "Top Novels as Voted by ISFDB Users". The maximum number of novels has been changed from 100 to 500, although at this time only 358 novels have more than 5 votes and are eligible for inclusion. The new data will become available overnight.
  • "Top Short Fiction Titles as Voted by ISFDB Users" has been added. The data will become available overnight.

The FR also requests that we:

  • Create sublists for novellas, novelettes and short stories, and
  • Create "most controversial" lists for these title types

I guess we could implement the first request, but we barely have enough short fiction titles with more than 5 votes for a meaningful "top short fiction" list. Sublists would be very short and hardly useful.

"Most controversial" lists are easy to implement, but would they add value? Ahasuerus 17:48, 26 October 2019 (EDT)

What would be on a "most controversial" list? ···日本穣 · 投稿 · Talk to Nihonjoe 16:06, 28 October 2019 (EDT)
Titles which have both low scores and high scores. For example, consider Paraworld Zero, which has three "1" votes and six "10" votes. The SQL code would look like:
  • select std(rating),title_id from votes group by title_id having count(user_id)>3 order by std(rating) desc limit 50
We could change "controversial", which was popularized by Reddit a few years ago, to "polarizing" or something similar. Ahasuerus 16:33, 28 October 2019 (EDT)
That's basically what I thought it might be, but it's good to know for sure. ···日本穣 · 投稿 · Talk to Nihonjoe 16:44, 28 October 2019 (EDT)

Content field and varianting

Can we please disable the contents field when you edit a variant the same way we do for series and series number and make it derived from the parent? We will never variant omnibuses with different contents so it can be safely deriving from the parent (the way series do) or moving to the parent when varianting up. And it will also mean an editor does not need to remember to repeat the same value in each variant after they variant omnibuses. Annie 17:19, 29 October 2019 (EDT)

After sleeping on it, I think treating the "Content" field the way we treat the series field and the series number field makes sense. We will need to update the "Make Variant" software to move the "Content" data to the parent title and we will need a new cleanup report, but it's all doable. Ahasuerus 15:08, 31 October 2019 (EDT)

Imadjinn Awards nonfiction category

Can we add a "Best Non-Fiction Book" category to the Imadjinn Awards? Some of the winners are within the scope of ISFDB. Thanks! ···日本穣 · 投稿 · Talk to Nihonjoe 19:10, 30 October 2019 (EDT)

I thought moderators were able to create new award categories. Do you see "Add New Award Category to This Award Type" within the "Editing Tools" section of the linked page? Ahasuerus 14:32, 31 October 2019 (EDT)
I guess I missed that since it's so far down the page. All created. (^_^) ···日本穣 · 投稿 · Talk to Nihonjoe 16:17, 31 October 2019 (EDT)
Okay, Imadjinns are entered through 2019 winners. ···日本穣 · 投稿 · Talk to Nihonjoe 17:17, 31 October 2019 (EDT)
Excellent! Ahasuerus 17:18, 31 October 2019 (EDT)

Advanced Publication Search - Secondary Verification Source added as a selection criterion

As per FR 1304, Advanced Publication Search has been enhanced to support secondary verification sources.

Note that you can use this functionality to look for suspect verifications. For example, it turns out that we have 4 publication records which match the following selection criteria:

  • Publication Year starts with 20
  • Secondary Verification Source is exactly Bleiler Early Years

Since Bleiler Early Years was published in 1991, the 4 verifications found by this report are presumably in error. We may want to follow up with each verifier to determine whether s/he clicked the wrong verification source or whether s/he meant to use the "N/A" button. In at least one case the verifier apparently misunderstood how secondary verifications work.

As is typically the case when adding new dynamically changed drop-down lists, you may need to do a full page reload (Control-F5 under most browsers) to make everything work correctly. Please let me know if you run into any problems.

Next I plan to create a new cleanup report to find publications whose secondary verifications are "out of bounds". Ahasuerus 14:30, 31 October 2019 (EDT)

Awards titles when a title is changed

When we create a new award, its title (which shows only when you press Edit - on the view screen you see the title of the actual linked work) comes from the Title connected to it. Once created that value is not changeable. So when you change the title of a record (for capitalization purposes or and/& or dropping subtitles and so on or something along these lines), the Award title remain as is. So there are two choice:

  • Leave is as is - which I do not like on general principle - it is just sloppy :)
  • Delete the award and re-add it again (which while doable is probably not what we want to be done).

Can we either sync these titles to the one of the titles or make them editable (foe example here)? Annie 15:11, 31 October 2019 (EDT)

It's not just the "Title" field that can get out of sync with the title record, it's also the "Author(s)" field. There is nothing stopping an editor from re-pointing an award record to a completely different title record with different authors.
As for the reasons why the software works the way it does, well, it's kind of complicated.
The original award system was rather rudimentary and incomplete. When I rewrote it ca. 2013-2014, I replaced some components and kept certain other components. One thing that I did was separate "awards associated with titles" from "awards not associated with titles". The latter have titles and authors of their own; the former use the title/author data of the linked title record. In an ideal world, "awards associated with titles" wouldn't store separate title/author data elements in the database -- as you said, they are pretty much useless. However, the two types of awards share underlying database tables. Moreover, there are quite a few places in the code that expect these award fields to be populated. I ended up with a compromise solution: when a "title-based award" record is first created, the software copies the title record's title and authors to the award record, but then they are never used except in ineditable fields when editing the award record.
I guess the easiest way to get everything in sync would be to use the title/author values associated with the currently linked title record to populate the ineditable "title" and "author(s)" fields on the Award Edit page. Ahasuerus 15:37, 31 October 2019 (EDT)
Yeah, I was just dealing with a title this morning and forgot about the author but I can see how we have the same problem there. :) We also can make them editable (moderator only if need be) but that will mean remembering them AND a new report so we can clean the discrepancies. We have a similar case with the reviews - and there the title and author are editable (most likely because they are shown inside of the container that contains the review). But if we can just use the linked title, it will mean we do not need to worry about updating so that is better :) Annie 15:49, 31 October 2019 (EDT)

Elantris

Hebrew title

I added this title, but since I don't speak or read Hebrew, it would be good for someone who does to review it to make sure I didn't inadvertently make a mistake. Thanks in advance! ···日本穣 · 投稿 · Talk to Nihonjoe 20:17, 31 October 2019 (EDT)

Russian, Polish, Thai, and Portuguese releases

There are apparently Russian, Polish, Thai, and Brazilian Portuguese releases of Elantris, but since I don't speak or read Russian, Polish, Thai, or Portuguese, I have had difficulty finding them. I tried poking around, but couldn't find much. Any help with that is appreciated, too. ···日本穣 · 投稿 · Talk to Nihonjoe 20:22, 31 October 2019 (EDT)

I will add the Russian and Polish ones Annie 20:23, 31 October 2019 (EDT)
The Russian and the two Polish editions had been added. I also threw in the Bulgarian, Czech, Hungarian and Turkish editions for no extra charge. I saw two Romanian ones as well but we have a Romanian editor so I will ping him to see if he would like to add them and an Indonesian one (which I do not know at all but we can try to add) :) Annie 21:32, 31 October 2019 (EDT)
Awesome! Thanks! ···日本穣 · 投稿 · Talk to Nihonjoe 15:44, 1 November 2019 (EDT)
Any time. And I asked the Romanian editor to add the Romanian ones (and approved them and massaged them into shape). You may want to ping PeteYoung for the Thai one directly - he may not be paying attention to the Community group :) And probably Dominique for the Portuguese one(s). Annie 15:51, 1 November 2019 (EDT)
I've asked Pete, but I can't find an active user name Dominique. Do you have a link? ···日本穣 · 投稿 · Talk to Nihonjoe 15:59, 1 November 2019 (EDT)
Ah, sorry. I meant our very own Linguist - and I think he can also check the Hebrew one :) This is very useful for finding who can help with exotic languages when you do not know off the top of your head. Annie 16:04, 1 November 2019 (EDT)
Yup, I created that page. :) ···日本穣 · 投稿 · Talk to Nihonjoe 17:05, 1 November 2019 (EDT)
I'll have a look at the Hebrew and Portuguese ASAP (meaning later to-day). Linguist 05:37, 2 November 2019 (EDT).
Dealt with the Hebrew one here. As for the Portuguese pub, either I'm utterly plotzed this morning, or it's not there ! :o) Linguist 07:21, 2 November 2019 (EDT).
We don't have one on ISFDB, but I've seen a few mentions of it online. I'll see if I can find one of them. ···日本穣 · 投稿 · Talk to Nihonjoe 21:22, 15 November 2019 (EST)
Check GoodReads. I think I saw some there when i was chasing the ones I added. Annie 21:53, 15 November 2019 (EST)

Show pub information show when hovering over images on title covers page?

User:ErsatzCulture has created FR 1317, "Have pub information show when hovering over images on title covers page". Here is what the non-technical part of the FR currently says:

One of the things I like doing in ISFDB is browsing the cover art for a title, and seeing how styles and tastes change over time or between publishers.
However, IMHO it's a slightly "opaque" user experience, in so far as the page (e.g. http://www.isfdb.org/cgi-bin/titlecovers.cgi?28692 ) just presents a bunch of cover images at you, with no context about which pubs they came from, or indication of why they are in the order they are, unless you click through to an individual publication page.
It would be possible to add information labels for each image, but then the size of the page (in terms of screen real estate, not number of bytes) could get blown up quite a bit.
Could I propose a solution - albeit one only usable by desktop users - where if a user hovers over a particular cover image, information about that publication is overlaid on that cover image. (I think this is a UI concept "inspired" by some other sites/apps, although I can't think which ones off the top of my head.)

I agree that it would be useful to provide additional context on the "All Covers" page. However, I am not sure whether it would be better to show the additional information as "mouse-over" or to display the basics like "Lion Book 1953" under each image. We could even combine the two approaches by displaying the bare-bones data under each image and providing more information via "mouse-over". Ahasuerus 16:46, 1 November 2019 (EDT)

I vote for not relying on hover/mouse overs only... or at least to make it optional or even two separate pages? I want to even be able to search (Ctrl+F and so on) on the page for "Lion Books" for example and see all the covers for that publisher from that pub - without needing to hover over all of them Annie 17:10, 1 November 2019 (EDT)
I would split the discussion in two: 'mouseover for extra info which doesn't use additional real estate' and 'what info can we add to cover pages to allow searches'. The former is easy to agree to, the latter warrants additional scrutiny imo since it'll use up screenspace, no? MagicUnk 00:04, 2 November 2019 (EDT)#
Yes, my reason for proposing overlays was because of not wanting to bloat out the page, and having them only appear when hovering means that if you don't want to see that info, you don't have to.
Here is a screengrab of my dev version. This has been hacked to show the info on all covers, just to give a better idea of the info and colour coding I'm suggesting - in reality only one image (at most) would ever show this at a time. The publisher ID is shown as a placeholder for the publisher name, because the latter isn't currently pulled from the database when producing this page, and there was no point in altering that query if this idea isn't going to be approved. ErsatzCulture 11:33, 2 November 2019 (EDT)

default clones to having a date of 0000-00-00?

My most common error when editing is to forget to clear the date when I'm adding a clone. It would seem that when you're adding a new printing, it would always have a different data. TAWeiss 18:33, 1 November 2019 (EDT)

Clones are also useful when you are adding ebooks and/or paperbooks - where the date does often need to be the same. But I won't be opposed to making the field empty instead. Annie 18:47, 1 November 2019 (EDT)
I think an empty field would be our best bet. Ahasuerus 19:06, 1 November 2019 (EDT)
Since clones already have reuse check boxes, how about a "Reuse publication date?" that is unchecked by default? -- JLaTondre (talk) 19:12, 1 November 2019 (EDT)
Sure, we can do that. Ahasuerus 19:20, 1 November 2019 (EDT)
I like that MagicUnk 23:44, 1 November 2019 (EDT)

Flag to mark publisher name is author name?

I'm increasingly being annoyed with all the self-publishing through Createspace that causes publisher records to proliferate and starts to clutter searches with 'useless' hits. Could we have a flag added to the publisher records meaning something like "this publisher name is the author's for self puplishing" (don't have the inspiration to come up with something better, but you get my drift eh? ;) MagicUnk 23:56, 1 November 2019 (EDT)

Not that I do not want the flag but consider the publisher ‘Latin Goddess Press’ for example. Will you check the box there? Does making a company make it really that different? Or Eve Langlais (Look up the name as a publisher name). And then there are presses that start that way and branch out. Who is going to monitor when that happens and remove the checkbox? Now, a checkbox that says that the author name is used as a publisher name - that makes sense. But then again, see the Goddess publisher. :)Annie 00:07, 2 November 2019 (EDT)
I may not exactly have been clear, but that's what I'd want, a flag that says author name used as publisher name. And yes, there are some ambiguous cases where it's not so clear cut, or may change over time, as you point out but I believe the vast majority of these pub records would be correctly tagged. (As an aside, I was thinking about adding an 'imprint' flag too, but that would require much more maintenance, with all the takeovers and subsidiary vs. Imprint and whatnot so I don't think an imprint flag would be workeable) MagicUnk 03:52, 2 November 2019 (EDT)
Let me make sure that I understand the proposal correctly. We would add a new check-mark box or a "Yes/No" drop-down field to the Edit Publisher page, right? Where would this flag be displayed/used? In regular and Advanced publisher searches, I assume? Any place else? Ahasuerus 11:52, 2 November 2019 (EDT)
That's right; checkbox edited & displayed on the publisher page, and used in searches. MagicUnk 16:33, 2 November 2019 (EDT)
Don't show in the Publisher directory or mark them somehow there so it is clear what they are? Quite honestly, if we are reopening the Publisher page, we may as well also add a Language there - the same way we have for authors - while there are a few multinational publishers, most of them are single-language and I would love to be able to find all Hungarian publishers for example. Annie 15:10, 2 November 2019 (EDT)
Agree on the language. Would be useful for me too. I don't suppose we can add country, do we? (I suspect we'd run in the same trouble as I said above about adding an imprint flag) MagicUnk 16:33, 2 November 2019 (EDT)

Binti: The Night Masquerade

Binti: The Night Masquerade is one of those novella/novels cases that are too close to call even on a complete word count (to the point where it was eligible for both for most awards). It ended up nominated for 3 awards, all 3 as a novella. We have it as a novel. Before I leave a note there explaining why (we have some earlier novel winners as collections so we have precedents), I wonder if we should keep it as a novel or convert it to a novella. Thoughts? Annie 13:56, 8 November 2019 (EST)

I can do a word count estimate on it. I'll have to find a link to that Google Sheets tool, though. I have it somewhere. ···日本穣 · 投稿 · Talk to Nihonjoe 14:46, 11 November 2019 (EST)
I own a copy, did a word count when I primary verified it back then and had entered the results into the title record, including some more infos about it. Somebody must have deleted it! I'll look into an older backup and see if I can find the note's contents again. Jens Hitspacebar 16:30, 11 November 2019 (EST)
Found it in the database backup from 2018-03-31, the day I had primary verified it, and added the note's contents back to Binti: The Night Masquerade. Whoever deleted the note must have done it between 2018-03-31 and 2018-04-07, not more than week after I had added it. That's really annoying if it was done on purpose. Can someone please can take a look at the note now and check if the wording is clear enough so that it's not deleted again because someone thinks that it's worthless information? Jens Hitspacebar 17:27, 11 November 2019 (EST)
Good enough for me. Thanks for adding it. No clue why someone would delete it (but it is annoying indeed). Annie 17:33, 11 November 2019 (EST)

Proposed change: make the position of the search box in the nav sidebar "sticky"

Since becoming a more frequent user of the site, something that is increasingly annoying me - probably far more than it should ;-) - is the way that when a page (re)loads, you always go to the top of the page. (To be more exact, to a point where the first/most relevant input field is visible and in focus, but this is AFAIK much the same thing in practice)

This is annoying in scenarios like the following:

  1. Go to a long page with lots of links e.g. http://www.isfdb.org/cgi-bin/se.cgi?arg=venus&type=Fiction+Titles
  2. Scroll down to somewhere near the bottom of the page/table, and click on a link (title, author, doesn't matter)
  3. Decide that the page you're looking at isn't relevant, and press the browser's back button to go back to the results to see if you can find a better one
  4. Find that you are back at the start of the results, and now have to manually scroll back down the page to find out where you were before

Over the weekend I had a look through the site's code, and found that this behaviour is deliberate. Whilst focussing on the input field makes sense in the context of a user searching on a lot of different values, or making edits, personally I think the knock-on effect it has on more casual navigation is not ideal.

I would like to propose a solution for which I have a barebones working demo, to be found here. Note that when you scroll down, the search box always stays visible on the page, and as a consequence, if you click on a result and then use the browser back button to return to the list of results, you'll be at the place in the list you were previously at, but at the same time the search field will be focussed, retaining that aspect of the current behaviour.

(Note: because this is a rough demo, all the title and author links in the results table go to the same fake title page, and all the other links on these pages are broken.)

There are other potential related changes that could be made - some of which are discussed in updates to this old ticket, but those might well require more research and development, whereas the change as implemented in this demo is largely complete as-is, and should be fairly straightforward to add to the site.

Thoughts? —The preceding unsigned comment was added by ErsatzCulture (talkcontribs) . 11:01, 11 November 2019 (EST)

I like the moving search box. I also agree with the sentiment regarding having to scroll back down a large page. It does make some things more difficult. ···日本穣 · 投稿 · Talk to Nihonjoe 14:44, 11 November 2019 (EST)
As I said on SourceForge (see the discussion linked above) earlier, I like the proposed functionality. However, it requires a fairly recent browser version to work correctly. Based on our experience over the years, many of our users are suck with old browser versions for various reasons, so we need to make sure that the change doesn't adversely affect the behavior of old browsers. ErsatzCulture and I are currently discussing technical options on SourceForge. Ahasuerus 12:50, 12 November 2019 (EST)

The Russian awards

I had been working on some Russian titles and keep bumping into the awards so can we add:

as a start. All of those should be eligible for addition here... :) Links to their Fantlab pages - actual pages linked there but if you read Russian, that is the fastest way to get the idea of what is what... We can also go one by one as well but... might as well add the big ones together. Thanks! Annie 19:52, 11 November 2019 (EST)

Sure, I'll be happy to add them if we have the manpower to enter the data. IIRC, the last time the issue of Russian awards came up, we also mentioned:
Ahasuerus 09:24, 12 November 2019 (EST)
There are a few more of we want a good coverage. The Efremov for example. :) But we need to start somewhere. Started with a list of 20 and narrowed down a bit as a start. I would rather start with the awards that are active and visible and work from there than work on an award that had not been given since 1996 as a start. So we either dump all of them in and deal with empty awards for awhile or we take it slow. I can add a few more I want if we go for all at once. :) Annie 11:03, 12 November 2019 (EST)
"Take is slow" is perfectly fine by me. If there are no objections over the next day or two, I will create the requested award types. Ahasuerus 12:45, 12 November 2019 (EST)

(unindent) The requested award types have been created. They may need further massaging; I believe moderators can create and approve "Edit Award Type" submissions. Ahasuerus 16:36, 14 November 2019 (EST)

Yep. Thanks. I will work on them this weekend while Fixer is in his early monthly stages :) Thanks for adding them. Annie 16:48, 14 November 2019 (EST)

Who's the image source?

Someone recently uploaded a new cover scan over one I had loaded some time ago. It's a better image, so no problem there. My question is why does the text under the Fair Use Image Data state that I am the source and not the more recent uploader? ../Doug H 08:19, 12 November 2019 (EST)

That is weird. I even tried to delete your old image and that still left the license in place. And looking at the history, Mavmaramis did try to set the license to his name (Source=Scanned by User:Mavmaramis is there in his edit. So... a bug maybe? Or something else is going on. In all cases, we probably will need to see how many others are like that... Annie 12:41, 12 November 2019 (EST)
This is a known problem. See the helptext here. The image data must be changed manually (unfortunately). --Willem 13:01, 12 November 2019 (EST)
Aha. I do not do a lot of images (and I never replaced one as far as I remember) so I missed that. Thanks for clarifying! Annie 13:13, 12 November 2019 (EST)
And by description, it means all variable content: description, publisher, artist and source. Might be worth noting on the upload page. Thanks for the response(s). ../Doug H 14:31, 12 November 2019 (EST)

The Marvel series reorganization

We had the Marvel series organized based on where they belong on the timelines and the movies/series/comics split. Which made it useful for finding what books fall in line with which release.

For some reason, they had been reorganized in the last week or so based on their main character (and from looking at most of the series, not even based on the character itself but based on the brand name only - and most of those do have more than one incarnation). As we do not have the ability to have multiple series, we always have to chose but can whoever is changing that explain their reasoning and why such a huge rearranging of series had not been brought up to the Community before destroying the old organization and all the work that multiple editors had put into it? We may decide that we want them the way they are now but such a large scale changes without a single notice anywhere is against the spirit of the project. Thanks! Annie 12:26, 12 November 2019 (EST)

Since I am guilty again and the reasons were in part the same, I have answered it here, Christian Stonecreek 14:24, 12 November 2019 (EST)
So are we leaving it this way? TAWeiss 21:47, 12 November 2019 (EST)
Surely not, but it seems to have been discussed first. Stonecreek 00:24, 13 November 2019 (EST)
Lumping all books with the same characters in the same series as opposed to following the universe development (as was the old series structure) just sounds a bit incomplete these days. It was not a bad approach 5 years ago but things changes. But I agree that we need a discussion and if most editors prefer character based series, so be it. Annie 02:05, 13 November 2019 (EST)
What late universe development? Marvel had from very early on the tradition of guest-starring and has continually built on it with overlapping story arcs. Still, the individual title series ran on, with some special issues or series thrown in.
With this background and the question posted above, I propose to go on with the re-structuring. The past development (see the examples in the discussion pointed to above) has shown that we as a community had lost the sense of organization for such a complex and inherently illogical structure. Christian Stonecreek 09:59, 14 November 2019 (EST)
There are two ways to look at that. Is it more important that a book is about Spiderman or is it more important where in the timeline it falls and which novels connect to it based on the timeline? In a perfect world, we will be able to do both. As it is now, one of those will need to be offloaded to a tag. So even if we do go on and build again back based on the characters, preserving the rest of the information in tags should be mandatory. Or in notes where that makes more sense. If everyone prefers the character based, then so be it. But let's ping the few editors that were doing a lot of work on that series lately and check on opinions. :) Annie 10:14, 14 November 2019 (EST)
For Marvel, I'd think it'd be a futile attempt to implement a timeline, since fiction titles may be placed in every possible time-slot or - even more often - any point in time will not be identifiable. Christian Stonecreek 10:24, 14 November 2019 (EST)
Marvel (as a company) is reorganizing into waves (because of the movies but the comics and the novels are getting also reshuffled) - similar to how Star Trek and Star Wars (pre-republic and so on) had been doing. So when the dust settles, most novels can fall into proper timelines groups. We can wait for the dust to settle but please, let's not lose the information by just moving them and not adding either notes or tags. Annie 10:28, 14 November 2019 (EST)
At the very least, I would recommend grouping the books related to the Marvel and X-Men movie series. Simply lumping by character loses the connection in the stories, and those characters are different in many ways from their traditional representations. Presumably, this would apply at some level to the DC metaverse. TAWeiss 10:52, 16 November 2019 (EST)
I agree. Character based series for the metaverses turns us into a glorified Listmania - and when there is a SpiderMan/Avenger novel, it will get even funnier and absolutely useless. Of course, it would have been much easier to figure out the reorganization if the work already done was not wiped out already... :) Annie 21:18, 16 November 2019 (EST)
Well, more or less obviously, I don't agree. This approach has lead (and will lead again) to the mess that was and is still not repaired. Titles with more than series-defining character would have to be grouped into the overall Marvel metaverse. This would follow the way Marvel organizes its uni-/meta-verse: by having the character-driven title series and the occasional crossover story-arc (like 'Civil War'); thus it would be the most easy-to-grasp way of ordering things. A possible way to find story-arcs would be tagging. Stonecreek 09:49, 18 November 2019 (EST)
So, under your scheme, a crossover between Spiderman and the Avengers will go under which series? You need to chose one and then you will have both the second character and the era in the tags (and for completeness you will need to add the main character as a tag as well so people can only look in one place for all books related to a character and do not need both a tag list and a series...
The fact that you could not figure out how to clean-up and complete the work does not mean that the only option was deleting all of it. Annie 11:29, 18 November 2019 (EST)
A crossover between Spiderman and the Avengers would obviously go under Marvel metaverse. As Doug has pointed out: all attempts to get a consistent organization of the series by sticking to the publisher's 'scheme' will be proved futile, since it is per se not consistent. Christian Stonecreek 23:23, 18 November 2019 (EST)

(unindent)After some thinking, here is an idea:

  • Move all the novels which are in the movies/series metaverse into their own subseries under the metaverse (Marvel Cinematic Universe).
  • Use the Infinity saga 3 phases to split the novels into subseries (with further subseries if needed based on specific storylines or complete character-based sequences). That means that if a book falls after "Age of Ultron" but before "Endgame", it gets grouped with the rest of the books that are connected to it and all the post-Endgame novels are grouped together.
    • The titles of a lot of the novels and stories will need to be restored back to what they were before half of their titles (as recorded on Title pages) were stripped to be used as series names. All PVs will be notified for any change.
    • We should probably also have a "uncategorized" bucket for novels which we cannot find enough information about... but we can work on that.
    • There are probably a few novels that cross between eras - depending on the numbers, they may need another high level series.
  • Character names can be added as tags.
  • All non-MCU but still Marvel novels (the ones that are in the comics universe but not in MCU - if we do have any) stay in their original place (aka per character) until we have enough of them so that it makes sense to change.

That way we will create more than a Listmania list of "these books have this character but some of them are over there and not here because of a crossover" and will make it easy to find a novel or see what novels are available for a certain era in MCU (and then you can get a character-based list based on the tags). Any feedback is welcome. Without the ability to add more than one series per book, we need compromise and as we cannot use the Pub series for these (translations and what's not will stick them in different places), we need a rational plan that makes sense and does not turn us into one more incomplete list of books on the internet. If noone disagrees, I will work with the records and lay down the proposed separation here before I go and change everything (probably next week). Once we sort that one out, we can work on the DCU and DC series. One at a time. Annie 11:29, 18 November 2019 (EST)

I'm not much of a Marvel fan, so have been following this thread without understanding a lot of the details. I tried to figure out what was going on by looking for Marvel's take on how to organize the material, thinking that should for the basis for our series. Seems that even they don't have one way to deal with it. The medium (film, comic, TV, etc) seems to loom large as there are differences for the same character between them. Their fandom seems to recognize various universes (e.g. 616), but even these cross-over. Much as I personally dislike tags, I think the Marvel (Meta)(Multi)Universe(s) is too big to be considered a hierarchy of 'series' and should be abandoned and that sets of tags - like universe, character, medium be established and used to link stories together. Maybe series could be used to link small things with clear connections (like movie novelizations). ../Doug H 12:00, 18 November 2019 (EST)
The MCU (the movies/series universe) is basically its own thing - separate storylines and timelines (although they did versions of most of the main storylines from the main universes). But that is exactly the point - a novel about Spider Man in the MCU has the same name and maybe the same storyline as one in 616 (also known as the main comics universe) has as much to do with a Spider Man novel in 616 as with a Batman novel: someone fights crime and monsters - all the details are wrong and the novel can be either for Parker or for Miles Morales (or some other incarnation). Sticking these under one "series" just because they are both Spider Man novels does not make much sense.
We can always just organize based on the main line, with occasional series inside and be done (kinda what we do for Stargate SG-1/Stargate Atlantis. The crossovers across universes in Marvel's lines are not as many as these in the SG franchise (at last the SGs are in the same timeline and know about each other) and most of them are during the big events so they will fall into these really.
And Marvel are still shifting things. The whole three phases thing did not show up in any of their communication until a couple of years ago (if that). So I expect the dust to settle at some point... Annie 12:27, 18 November 2019 (EST)
Rather than trying to create an organization, can we find an authorative source and use theirs? And if there are multiple, let's argue about which to use, rather than what to create. We are primarily bibliographers rather than generators of information about these stories. ../Doug H 12:39, 18 November 2019 (EST)
Marvel Fandom: here is based on main groups and lines. Note the "Other Novels" bucket and the "Marvel Novel Series" which tend to shift often and get re-categorized. Wiki's list is just a flat list. So is comicweb. Marvel itself had never had a complete list anywhere. The Titan novels (here are kinds a series in their own as are the Doctor Who ones - they hold the license. So... make your pick. It's one of those "it's complicated" :) And sometimes we do need to order things that noone had bothered to yet. Annie 12:57, 18 November 2019 (EST)
It would seem that just re-organizing the MCU stories into their own hierarchy is relatively straightforward change that does not impact the majority of the entries, but does impose a logical structure on those titles. (As a fan of the series, it's what I'd expect to see.) Should we do the same for the other movie novelizations (Fox X-men, Daredevil, Blade, Elektra, Fantasic Four)? It would seem better to leave them be since they are more localized (though the X-Men ones should be pull their novelizations into their own subseries). TAWeiss 17:59, 18 November 2019 (EST)
Do we want to try to compile a list of the MCU ones so we can see what is in there and then decide how we organize them? I would say one at a time. Let's deal with the MCU first, then see how it looks and decide if we need to pull/change more. Most of the DD/Elektra (pre-MCU, not anything based on the current series), FF, Blade and the older X-men are pretty self-contained anyway... What do you think? Plus that can give us a blueprint for sorting the DC mess as well where it is at least as fun (even if DC-TV is mostly series and not movies based, they did build a separate universe). But one at a time. Annie 18:24, 18 November 2019 (EST)
Starting working on the list here —The preceding unsigned comment was added by Taweiss (talkcontribs) .
Thanks for working on this! Annie 15:20, 24 November 2019 (EST)
Finished listing out the MCU novels. There are some bridging material as well that fits between movies and some prequel material. It may not sort well into phases, but is consistent with the overall story and characters. TAWeiss 18:46, 24 November 2019 (EST)

A proposal to solve the art battles

After I have been asked to redefine the language of a piece of cover art for which the title is stated in English on the copyright page to German, there has been some conflict. In my opinion a 'reality' in which paintings are assumed to be made up out of language and not by using brushes, pencils & colors, shouldn't be the basis for a database that is enlisted to give a picture of reality - and it doesn't get better by further assuming that the reproduction on the cover (or inside) of a foreign publication is redone or translated by using a different language denominator for the variant, which does mark for the unsuspecting eye that somehow words of the different language were used in the reproduction. This all just is done to have a picture or list of the languages a piece of art is published in (with no language involved in the artwork at all).


Now, to repeat: I strongly think that this is a reality-bending approach that stands against plain logic (and our goal to display aspects of reality). However, what about a totally different approach that even more people might be interested in (for example me). The idea would be to display the country of issuing of a given publication, at least on the title level list of publications, for example by using standard abbreviations (US, UK, FR, RU, DE and so on). For most publications this should be quite easily to obtain via the ISBN (for others there obviously would be work involved, but it should be possible to adapt to it, most likely via the country a publisher is situated).

This way we would get rid of the conflict and the unreality bias, but would even gain more information, for example on which side of a given ocean a publication with purely English, French, Portuguese or Spanish titles in it was published. Stonecreek 06:03, 15 November 2019 (EST)

Having thought again about it, it might be necessary to go the way via publisher, perhaps by entering a field for country?. Stonecreek 10:58, 15 November 2019 (EST)
You know, that is not a bad idea IN ADDITION to a language. :) This way we will have both the language (so we know that the cover had been used in German for example) but also where in the German-speaking world. However, a few pesky details. What country will be assigned for the following cases?
  • Russian language book published in Germany
  • US publisher printing in Canada
  • Thailand publisher publishing in English and printing in China
  • Dutch language book from a US publisher printed in USA
  • Dutch language book from a US publisher printed in China
And what is your proposal for cleanup of the existing 184,457 covers and 231,588 interior art records and assigning their countries? We cannot just go one by one and we cannot assume that language means country.
Also please note that regardless if this proposal is approved or not, the current rules still apply and you cannot NOT conform with them. And even if it is approved, it will significant development effort and we cannot just suspend the rules in the meantime or ignore editors that refuse to abide by them. Annie 11:53, 15 November 2019 (EST)
It sounds like there are two separate questions here. The first one is how we should record a COVERART title which uses the same artist name, the same title and the same art/painting, but is associated with different translations of the same book. For example, George Orwell's Nineteen Eighty-Four has appeared as 1984 in dozens of languages. If a French edition were to use the same cover art as a Dutch edition, should the two COVERART titles be merged or varianted? The current policy is that they should be varianted.
The second question is whether we can record and display the country of origin for some of our records, be they titles, publications or publishers. Publications would be relatively easy to do, but we'd need to decide how to handle simultaneous publications. There are quite a few publishers with offices with multiple countries these days. Also, a lot of independently published books appear on Amazon.com, Amazon UK, Amazon CA, Amazon AU, etc almost simultaneously.
Publishers would be even harder to associate with countries, because a publisher, especially a small one, can easily move to another country. Not to mention that countries' borders can change over time, countries can break up, etc. And I can't think of a realistic way to link title records to countries.
I should also point out that, although "countries" and "languages" overlap, there is no one-to-one correspondence. As Annie suggested, certain languages like Arabic, English and German are used in multiple countries while many countries have publishers producing books and magazines in multiple languages. Ahasuerus 16:44, 15 November 2019 (EST)
All the problems you name are non-existant with the approach of dropping the language for art titles. On the contrary, it would help to solve them. Let's take the example of a Russian book published in the USA, and let's take the example further by assuming that it's a book about early speculative fiction with a reproduction of the cover of this publication on its cover (titled 'De la Terre à la Lune / Autour de la Lune' on the copyright page), and reproductions of the cover art pieces of this, this and that respective publications, with additional examples from other countries thrown in. One can only presume, but according to your scheme, I think all the art pieces would get the English language attributed (since it's a US publication), or maybe the Russian? With no language attribute for art titles (since no language was used in creating them), the problem of assigning a language to them wouldn't even arise! Stonecreek 02:17, 16 November 2019 (EST)
So let's delete and lose information just so that you do not need to abide by the rules of the site (the ones you disagree with anyway)? :) That's what variants are for - put the original as the original, then variant the reproductions. We are a DB - advocating the removal of information and various changes in the rules (hide languages inside of pub lists for example or hide dates the same way) which make the information either hard to find or impossible to decipher kinda sounds against the best interests of the project. Annie 21:15, 16 November 2019 (EST)
Yes, we would lose erroneous information (language that does not exist), but I'd think it is a goal of ISFDB to enter correct information, not fake news. Stonecreek 01:31, 17 November 2019 (EST)
The language assignment shows what language was the book that used the cover in. How is that fake news? Or are you claiming that the books do not have language either? Don't think so. You keep getting stuck on putting an equal sign between coverart and cover art. The first is our record that has the art but also has notes, and variants, and language and exact spelling of the artist and so on. The second is the piece of art - which does not have a language. Or multiple spellings of the artist.Annie 02:05, 17 November 2019 (EST)
PS: Just because you do not find that information useful, does not mean that noone does. I find it fascinating to see how many different languages and cultures use certain covers for example (probably the only thing about covers I care about). However, if the consensus had shifted and we had agreed to merge, I would have not gone against it. There are other things in the DB I never look at or care about but as someone may find them useful and we are recording them, I record them on my books, moderate them and even mentor new editors to add them. It is all in the balance. Hiding and removing information, even just obscuring information, just because we do like it or would never use it or do not believe it should be recorded will lead to a degrading quality quickly. You know, I do not care about under what exact author name had a story been published or what spelling the editor of a magazine used for the title - after all they have legal names and the stories have titles. Should I start deleting pseudonyms and variants? Surely having the same author spelled in 10 ways is useless information? Or having the same story spelled in 4 ways because of a comma or a hyphen? I find that as weird as you seem to find the idea that the cover should share the language of the book it belongs to. So shall I just go against the rules and the consensus and make them look how I want to? I know that I will never get the consensus to shift so I just implement the rules as they are - small price to pay for having ISFDB and being able to help. When we go on the slippery slope of "an editor does not like this so they do whatever they want", that becomes a valid question. Let's not go there, shall we? :) Annie 22:37, 16 November 2019 (EST)
Again: they can't use a language that doesn't exist. The cultures that use a particular work of art are covered by the country of the publisher more properly! A Russian book published in Germany would be aimed at (a part of) German culture, just as this is aimed at a part of German culture interested either in learning English or in science fiction (or both).
Let's take another example, Tom Disch's Endzone. (Un)fortunately it has no cover art credit, but please tell me, if it had, what should it's language be? 'Endzone' is a valid title both in English and in German. The book is categorized in English, although more than half of the text is in German (the translations and most of the essays). As is easy to see the publisher is situated in Germany, and a cover artist would presumably be one with a working language of German (the publisher's designer is). And for the interior art: Does its 'language' depend on where in the book (in an English or in a German part) it is printed (but what if it's printed in between)?. Or shall the title rule in this case?
It's fine for you to be interested in art (I am also, but perhaps to a slightly smaller degree), but we are not an art database, instead one that deals with speculative fiction. All those pointlesse debates that arise by assigning language to artworks pointed to in the paragraphs above would not come up, if we drop this made-up assumption. Christian Stonecreek 01:31, 17 November 2019 (EST)
Language and country is not the same thing. And the languages we have, the countries we don't. Come up with a plan on how to find the countries of all books in the DB? And you never answered which country will be chosen in each example above. I like the idea - we were talking abour adding both languages and countries to publishers somewhere a few weeks ago. But as an addition, not as a replacement. And for a book (and a cover) published in Kiev (for example) in 1972, knowing if it is in Ukrainian or on Russian is a lot more important than the fact that it is in Ukraine, USSR. Or that a Russian language book in 1980 was published in London from a UK publisher. From cultural and historical and bibliographical perspective anyway.
For multi-language books, how do you chose the language for the reference title? Someone decided that the Collection is an English title somehow. Same logic applies. If anything, it is the non-art title that is jarring here :) We do need "multiple" for these books (a lot of art books are like that as well). And fascinated and interested are different things. I can live without all the art here. But as we have it, let's not hide it and let's make it as easy to find the information for it as we can. I get it - you do not like it. But you cannot get anyone to agree with you either and support you in a rules change. Get the support, change the rules, I will be the first to help with the cleanup (I seem to always be doing some cleanup). Are we really spending our time in the best way arguing over that and cross-editing over and over? :) Annie 02:01, 17 November 2019 (EST)

(unindent) I think I see three separate issues here. The first one is whether COVERART titles should have language codes associated with them. I certainly see Christian's point, i.e. that works of art generally do not have language-specific information embedded in them. You could plausibly argue that we should create a "no language" code and add it to our list of supported languages. The ISO 639-2 standard, which we use as our guide in the language area, has a special code for it, "zxx - No linguistic content; Not applicable". It's a reasonable perspective and it has been discussed at length over the years.

At the same time, there is value to having language codes associated with COVERART titles. Consider Les Edwards, who was mentioned earlier. When you look at his Summary page, you can immediately see all the languages that his covers have been associated with, e.g. the cover of The 2nd Mayflower Book of Black Magic Stories was later used as the cover of the Polish magazine issue "Fenix, V4 #3, 1993". That's very useful data and the consensus of previous discussions was that its usefulness outweighs the "cover art has no linguistic content" argument. Personally, I agree with it, but, more importantly, it is the current consensus. As moderators, we must enforce it until and unless it has been changed. My job as a bureaucrat is to make sure that moderators follow the consensus regardless of their personal preferences. Please follow the consensus.

The second issue is the cover of Simulacron-3: Welt am Draht. The Note field reads "The cover art is credited and titled "The Last Elevator" on the copyright page." I don't recall coming across this scenario before. I'll need to read up on the history of the issue and think about it before I can comment further.

The third question is "language vs. country". Languages and countries can overlap, but they are very different animals. Consider the Kurdish language spoken by some 30 million people who live in a number of countries. Consider Telugu, spoken by over 80 million people. It's the 15th most spoken language in the world, yet there is no country with a Telugu-speaking majority. Consider Austria-Hungary, none of whose ethnic groups accounted for more than a quarter of the empire's population. Consider the Russian Empire, whose pre-WWI population was less than 50% ethnically Russian. Consider Belgium, Czechoslovakia, Yugoslavia. Heck, consider Southern Sudan with its 60+ ethnic groups. The list goes on and on.

Even countries with a single dominant ethnic group can have a thriving ethnic minority with a steady stream of publications in their own language, e.g. the Swedish minority in Finland. Emigre groups can publish books in their native language and try to ship them back to their country of origin, e.g. see this first edition (published in West Germany) of this Russian novel. Etc.

I am open to ideas and suggestions, but I don't think we can come up with a way to link languages and countries in a structured, database-friendly manner. Ahasuerus 21:35, 17 November 2019 (EST)

On Telugu (and all other languages pointed at here): The point I'm making is that language doesn't matter in viewing a piece of art (or listening to a piece of pure music), it is the culture that may matter (though in these times of global linking, it does so less and less). I am making my point from a German point of view: Here, the Turkish people are by far the biggest minority stemming from a foreign country. But they are as a whole no part of the Turkish culture anymore, they are also part of the German one (if they or German nationalists like it or not). The vast majority of the initial immigrants had planned to stay a few years and go back to their country of origin, but virtually no one did. And that's so because they are viewed there as Germans (this happens even between Austria and Germany, two countries seemingly culturally undistinguishable from outside of Europe). A book published in Turkish by a publisher situated in German may serve a) nostalgic feelings b) help educate people (based in the Turkish, German or any other language), c) reflect on the cultural differences (or commons) of cultures, d) serve the entertainment with any possible kind of cultural background). In this and any case mentioned above it is aimed at people living in the country of their choice (or maybe forced to live by circumstances). Thus, the country of publication is the first interesting thing for a given title, the title of the publication is the second. It seems you and me are interested in cultural diversification, and thus we would immediately be interested in a publication with a Cyrillic title published in the US. All of the titles (minus the artworks) would have languages assigned to them and are justly represented. Artworks don't rely on languages and would be represented by the country of the publisher and their title proper.
To assign a country to every publisher would be a huge task (the likes of which we are adjusted to, see the assigning of working languages to authors). On the other hand, I would estimate a number of 1,000 - 2,000 publishers (the 'big players') to capture the vast majority of reproduced art in a first step (for example ancient publications don't matter for this problem). Sounds manageable to me within a year or so. Christian Stonecreek 04:42, 18 November 2019 (EST)
I agree that there is a certain amount of value to knowing where a publication was published. Traditionally, librarians who use the MARC family of bibliographic standards captured "place of publication" information in field 260, subfield "a". At this time we capture it in our Publisher records' Note fields, e.g. "Based in Barcelona, Spain" or "Based in Stockholm as of 1975". We could try to make the way we capture this data more robust, e.g. by creating a separate Publisher field for "Place of Publication", but it would need a fair amount of design work and would likely be complicated: some books are simultaneously published in multiple countries, some publishers move from country to country, etc. Linking this information to Publication records would also be difficult.
Having said that, I don't see how changing the way we capture the "place of publication" information would affect the way we capture and display the language of COVERART titles. As I said earlier, location/country and language are different animals. "Place of publication" is a publication attribute while "language" is a title attribute. Linking them would be both difficult and against the way the ISFDB data is structured. Ahasuerus 13:02, 18 November 2019 (EST)
Well, the initial proposal was to drop the language for art titles altogether. And I see a general problem using functions of the title (here language) to point at publications that have no language assigned to them. Christian Stonecreek 23:51, 18 November 2019 (EST)
To go back to the original question, we do not record a piece of art, we record art used in or on a publication. I.m.o. the language of the publication is leading for the language assigned to the art title. No, the art itself may not have a language, the use of the art certainly does. Of course there will be borderline cases (multi lingual publications ets), but these are exceptions and should not be used to make a statement about this issue. I strongly disagree with the idea of dropping the language for art titles, and though the idea of adding a country field to publishers is nice, it would only lead to more confusion and pointless discussions as far a art titles are concerned. --Willem 07:05, 18 November 2019 (EST)
As you should be aware of this would prove quite difficult to fulfill, since publications have no language assigned to. It would have been possible in times where there was no more than one language in the database, but it is the multilinguality that makes things quite complex (even more when it used for cases that are not made out of one of its components). And if you would have looked into the Disch example pointed to above, you would have been aware of that problem. Christian Stonecreek 09:19, 18 November 2019 (EST)
As you should be aware of, 99.9% of all publications contain only writing in one language. You keep pointing out the few exceptions. I have looked at the Disch example above, and so what? Apart from other problems with that pub a unsourced dating of some poems, how many of those are in the database? --Willem 09:29, 18 November 2019 (EST)
Even for the multi-lingual books, we chose 1 language for the reference title and each book has a reference title. Having the cover art match that title makes this choice trivial and consistent and in line with any other book. If we are going to discuss languages and multi-lingual books, it is not the art we should be starting from, it should be the reference title. Because for some reason in the Disch example, it is the coverart that is the problem and not the container language. And that makes no sense. Annie 13:28, 18 November 2019 (EST)
Well, I should say it makes perfect sense. The container title is a COLLECTION, with English and German language on a par, but the poems were written in English and are the leading titles. And it is the container title that sets its language. Christian Stonecreek 23:51, 18 November 2019 (EST)
I would be against dropping the "language" attribute of coverart titles. Since others have already stated what I would state, I'll leave it at that. ···日本穣 · 投稿 · Talk to Nihonjoe 01:46, 19 November 2019 (EST)

'Add Artist' buitton

I'm trying to co-credit a second artist here but when I go to its Edit page, the 'Add Artist' button is not there. The coverart guidance doesn't seem to cover it. http://www.isfdb.org/wiki/index.php?title=Template:PublicationFields:CoverArt

What am I missing here? Thanks, Kev. BanjoKev 12:17, 15 November 2019 (EST)

The cover already exist and is used in more than one publication so you cannot change it inside of that publication. You need to go on the title level (here and edit from there). :) Annie 13:58, 15 November 2019 (EST)
Aha! Thanks :) Kev. BanjoKev 15:33, 15 November 2019 (EST)

Split publications outside of magazines

Apparently we need to open/reopen the discussion. My understanding of this had always been that IF a novel is split for publication in book form, each part is still called a novel, has its own title record that shows the split with disambiguation if needed and is varianted into the main title. See Dune for example. I asked about it early on and the help page explains split novels the same way - and the French tend to split a lot so we have thousands of those in the DB. I will try to find some of the old thread and update this message with them as well. However, the German publications seem to follow a different model: see this discussion and this example or this example - separate publication titles BUT all using the complete novel as a title (which under our way to record looks like a claim that the novel is printed inside of each volume in its entirety). That makes the DB inconsistent.

What is the current community consensus? We have 3 choices:
  • Stick to the rules - aka - separate titles, original type remains and then varianted up to the full work and fix all those German novels that are now out of compliance. Example - Dune above (the French titles, the Japanese ones and the Serbian ones for example).
  • The German model - I am not a fan of it because it makes it impossible to find what novels had been split without looking at all the publications one by one but if everyone likes it, then we can use it and then we need to convert half of our French books to use it (for example)... Example: the two German titles above.
Of course, if we go that way and the two parts of a novel have a separate translator, we will have an inconsistent DB.
  • Update the rule on SERIALS and make all of those split publications SERIALS regardless if they are in a magazine/fanzine or not.

Thoughts? Or am I misreading something in the different handling? We cannot do different things based on language - not on that fundamental level. Annie 17:50, 15 November 2019 (EST)

The last idea doesn't seem bad: as of lately there's the habit to publish portions/chapters of a NOVEL first as separate CHAP ebooks. Christian Stonecreek 02:23, 16 November 2019 (EST)
I have never liked the current approach of making something that is only a portion of the entire work a variant of the full work. Handling the situation as a SERIAL appeals to me. --MartyD 07:54, 16 November 2019 (EST)
Re: novels serialized as CHAPBOOKs, the data entry rules were changed to allow the use of the SERIAL title type in CHAPBOOK publications on 2018-11-29: The SERIAL title type is to be used when a work is serialized across multiple chapbooks.
Re: novels which are split into 2+ novel-length books when they are reprinted or translated, I guess there is another possible approach: keep the current VT method, but implement FR 1186, "Create a Title disambiguator field", and use the new field to document the nature of the relationship between the VT and the parent. I am not sure it would be ideal, but it's something to consider. Ahasuerus 11:23, 16 November 2019 (EST)
Why not just call those serials as well and be done with it? What’s the difference between splitting into 35K words chunks (chapbooks) and 45K words chunks (now it is not) and who is going to count? We kinda play it by the ear with the chapbooks on that updates rule (we know the Dune In 3 books is not a chapbook) but still - why keeping an artificial difference and have one more place where the type and behavior is based on word number? Annie 11:29, 16 November 2019 (EST)
We have been slowly expanding our use of the SERIAL title type, e.g. see the 2018-11-11 and 2018-11-29 changes in the Rules_and_standards_changelog. I guess we could expand it further and include "part of a NOVEL title which appears as a standalone NOVEL publications". The standard SERIAL naming conventions, i.e.:
  • If the title of a SERIAL part is unique, e.g. "Butterflies in the Kremlin, Part Eight: As the Bear Turns" or "Ciężki bój (cz. 1)", then use the full form of the title. If, on the other hand, the title is shared by at least one other SERIAL installment, append a space and a parenthetical statement such as "(Part 1 of 3)" to the title.
should probably work OK. Can anyone think of any issues that may arise? Ahasuerus 15:40, 16 November 2019 (EST)
Besides the cleanup effort that will follow - type change in all languages besides German, unmerges, renames and varianting for the German ones, I cannot see a harm in this approach. Not sure how we can catch those on a report so it will be mostly adhoc but at least we will stop having different practices across languages. Annie 16:27, 16 November 2019 (EST)
And if we are adding this, we probably should officially allow serials in collections and anthologies as well - no point having special rules for serialized stories there when any other serialized content goes under serials. And some people had been adding them this way anyway - some left over after magazine to anthology conversions, some intentional. Annie 16:37, 16 November 2019 (EST)
Pardon a focused perspective - So for L'île mystérieuse (Mysterious Island for the English title) - the first three publications (Parts 1, 2 and 3) would become SERIALs that precede the publication of the single compendium novel but variant to the same title record. Does the TITLE date change to the date of the full novel rather than the first part? And the translations of the parts become SERIALS that remain as variants to the full French title, rather than to the parts they correspond to. Which you couldn't do as you can't have variants of variants and makes sense for the two-part Romanian translation of 1979 which wouldn't have corresponding parts. There does not appear to be an Add New Serial under the Add New Data:, so how does one go about creating a SERIAL. Do you generate a dummy MAGAZINE with the various parts, variant them to provide anchoring links and then delete the magazine? Or create them as NOVELS and change the TITLE type? Or would changes be made to allow us to select the TITLE type when creating NOVELs, CHAPBOOKs and anything else we extend this SERIALization to? ../Doug H 20:03, 16 November 2019 (EST)
You add a chapbook with the SERIAL record instead of short fiction. :) Then the serial get varianted into the novel. The question of what we do with first publication date is good though - when the serialization is in magazines, we need a first book publication; when the first is in a chapbook, what do we want to do? Annie 20:28, 16 November 2019 (EST)
What if each portion of the serialization is novel length? Does it still go into a CHAPBOOK? Or would you create as a CHAPBOOK and then modify the publication to be a NOVEL? Would that leave the TITLE's title type as a SERIAL?../Doug H 11:04, 17 November 2019 (EST)
Just stop thinking of a chapbook as a container for a story. It is a container for one piece of fiction that cannot stand alone: SHORTFICTION, POEM, SERIAL. Serial does not have length - so can be used regardless of how big the chunk is. Same way how a Complete Novel inside of a magazine is still a serial :) Annie 11:43, 17 November 2019 (EST)
Rules state CHAPBOOK is a container for a SHORTFICTION, POEM plus ESSAY and INTERIORART. Putting a NOVEL in would require a change in the rules. The thread is about implications - there's one. ../Doug H 12:58, 17 November 2019 (EST)
But we are NOT putting a novel, we are putting a SERIAL. And we already allow that and have a lot of those (usually shorter but SERIAL is a SERIAL and we never put a limit on length officially) - see the change from last November. The software now allows a SERIAL as the piece of fiction in a chapbook (See the serialization here for example). If we had not updated the rules somewhere, please post the link where we do not have it and we should be fixing that. :) Annie 13:12, 17 November 2019 (EST)
This help is where I got the quote about CHAPBOOK, which does not include NOVEL (unnecessary as you pointed out) or SERIAL (as proposed). So the pub Vingt mille lieues sous les mers: Première partie will become a CHAPBOOK and the contained TITLE Vingt mille lieues sous les mers: Première partie becomes a SERIAL, and the title will move from the Variant Titles to Serializations under the Other Titles section of the Summary display for the base/full novel entry Vingt mille lieues sous les mers? ../Doug H 14:55, 17 November 2019 (EST)
Actually, that page also says: "SERIAL. Use for a title that would otherwise be either SHORTFICTION or NOVEL, but which is being serialized in a magazine, a fanzine or a series of chapbooks. Also use when a novel length work (40,000+ words) is printed as a single installment in a magazine or fanzine issue. Note that all newly added SERIAL titles need to be turned into variants once the original submission has been approved -- see Help:How to connect serials to titles for instructions.": (bold is mine). So we did update it for the case where it is chapbooks clearly and not volumes of a novel. But we do need to update the Publication_Type tab list. So I am posting a separate thread Annie 15:09, 17 November 2019 (EST)
Yep, that's the idea. The change that allowed it for actual serialization-in-chunks was recorded here, we need to update the help pages. Now the idea is to open it for any "published-in-chunks-in-separate-books". I will start a separate thread on the help page change. Thanks for checking the page. Annie 15:04, 17 November 2019 (EST)
I like this idea. I will gladly help cleaning up this mess, starting with The Green Mile, that one even has a boxed set of the 6 chapbooks defined as a novel :) --Willem 07:41, 18 November 2019 (EST)
Looking at Help:Use_of_the_SERIAL_type#Date_Rule, I see:
  • There is a deep and abiding divide between the way short fiction and novel length fiction pieces are cataloged by genre (and mainstream) bibliographers. When cataloging short fiction, the date of the original publication is always used as the "publication date" regardless of whether the original appearance was in a magazine, anthology, collection, or a chapbook. However, when cataloging novel length fiction, the date of the original serialization is not used and the date of the first book publication is used instead. This is an old (and arguably unfortunate) bibliographic convention, and we follow it.
  • This is the main reason why we have to display SERIAL appearances on the Summary Biblio pages: otherwise many (perhaps most) ISFDB users who are not familiar with this convention would never check the Title page and assume that the first appearance of Skylark was in 1946 etc.
  • The reasons for this divide are twofold. First, serially published novels are/were often extensively rewritten prior to book publication (e.g. the Lensman saga), so it's natural to think of these two versions as separate works. Second, the world of book collectors is somewhat removed from the world of magazine collectors. To a book collector, a "first edition" is the first book publication of the novel in question, not its first magazine publication.
  • The possible difference in content supports this rule, as does the desire to display, on summary pages, both the date of first serial publication and the date of first book publication (for novels) or first non-serial publication (for short fiction).
If we are going to start using the SERIAL title type for novels which were subsequently broken up into shorter novel-length publications, the reasoning cited above will no longer apply.
One possible approach would be to abandon this distinction altogether and use the same date rules that we use for all other title types. We would be breaking with the "old and arguably unfortunate" bibliographic tradition described above, but it would make our date data much more consistent and intuitive, especially on authors' Chronological pages. Granted, it would require a significant amount of cleanup since we currently have 13,298 SERIAL titles. We would also have to decide whether we use the date of the first installment or the date of the last installment as the date of the parent title. Ahasuerus 10:35, 17 November 2019 (EST)
But the dates of later serials are irrelevant for the first date of the novel. The case we are still looking at is serialized before first publication. The question is: if that first serialization is in chapbooks and not in magazines, do we keep the dates separate. Or am I missing something? Annie 11:53, 17 November 2019 (EST)
The approach that I described above would mean that the date of the parent NOVEL title would be the date of its first publication in any form, be it as a standalone edition or a serialization in any form. To use the Skylark of Space example above, the novel was first serialized in Amazing Stories in 1928. It was first published as a book in 1946. Under the current rules, the date of the parent NOVEL title is 1946. Using the approach described above, it would be 1928. The same logic would apply to serializations in CHAPBOOK pubs, NOVEL pubs, etc: the date of the first public appearance of a text would be the date of the parent title. Ahasuerus 12:13, 17 November 2019 (EST)
I got the idea, but above you said "If we are going to start using the SERIAL title type for novels which were subsequently broken up into shorter novel-length publications, the reasoning cited above will no longer apply.". And I was pointing out that it is not the novels subsequently broken up that are the problem for the dating rule. It is the ones that were originally published broken up (think the Victorians or all of the chapbooks and serialized works that are published these days pre-novel). Annie 12:46, 17 November 2019 (EST)
What I was referring to was the Help explanation that "the world of book collectors is somewhat removed from the world of magazine collectors. To a book collector, a "first edition" is the first book publication of the novel in question, not its first magazine publication." In other words, "magazines are one world and books are another world". The SERIAL data type was originally created to support the "magazine world" and it used "magazine world" rules.
However, once you start using SERIAL titles within CHAPBOOK publications and -- if this idea pans out -- NOVEL publications, the distinction becomes blurred. And if the walls separating the "magazine world" from the "book world" crumble, then you could argue that there is no longer a reason to have separate date rules. Just use the "first date of known public appearance" rule for all title records and be done with it. Ahasuerus 15:30, 17 November 2019 (EST)
It was the word "subsequently"(as opposed to "previously"/"pre-first complete publication") that my just awaken brain caught up on. We are on the same page here. :) Considering the blurring of the line between anthologies and magazines these days (half of the time, only the editor can tell you what they are publishing, especially for the ones coming once a year - and a lot of the current small-print magazines miss any letters or columns making them indistinguishable from an anthology series really besides the "issue #" on the cover), it may be worth looking into. Annie 15:46, 17 November 2019 (EST)
That's one of the dating rules that always tripped me - it ends up with variants published before the parent. I understand why it was adopted but... outside of the US magazines, I am not sure that the rewrite for the book really applied anyway. And we could have done something a lot more logical (on a parent, show two dates - first non-serialized and first serialized for example) instead of having a serial from 1956 showing in a 1960 entry. But them are the rules. I'd be happy to change them and do the cleanup if need be - but it is not mandatory in order to adopt SERIAL - we just need to come up with a non-magazine rule :)Annie 12:46, 17 November 2019 (EST)
Re: "on a parent, show two dates - first non-serialized and first serialized for example", a number of similar approaches have been proposed and discussed over the years. Unfortunately, each one ran into some "gotcha" or another, so nothing was ever finalized. It all went back to the original decision to handle magazines and books differently, which made things complicated. The current idea, if implemented, would address the underlying issue, and may be the most promising one yet. We'll need to think about it and, if we can't identify additional problems, post a cleaned-up version of the proposal on the Rules & Standards page. Ahasuerus 19:34, 17 November 2019 (EST)

(unindent) I am re-reading this discussion and it looks like we have two different (although complementary) data entry rules changes being proposed.

The first one is to change the way we handle "split novels", i.e. NOVEL titles which have also been published as 2+ novel-length books. The current rule as per Template:PublicationFields:PubType is to treat each individual sub-book, which I will call "segment" for the purposes of this discussion, as a NOVEL title within a NOVEL publication. The proposed new rule is to treat each "segment" as a SERIAL title within a NOVEL publication. An alternative version of the proposed new rule is to treat each "segment" as a SERIAL title within a CHAPBOOK publication. In both cases we also need to decide how to date the "segments" if they appear prior to the single-volume appearance of the main NOVEL title.

The second proposed change is to the rule which determines the date of NOVEL titles which were originally serialized. The current rule says:

  • when cataloging novel length fiction, the date of the original serialization is not used and the date of the first book publication is used instead

The proposed new rule is to use the date of the first installment of the first serialization of the text. An alternative version of the new rule would add the word "complete" before the world "serialization" since serializations sometimes die before they are finished.

I guess the first thing to do is to decide whether to post these two proposals on the Rules & Standards page as a single combined proposal or as two separate proposals. If we decide to post them as two separate proposals, then we need to decide which one will be posted and discussed first.

The main advantage of posting them as a single proposal is that it would present a comprehensive self-contained solution to the various SERIAL issues that we have been dealing with for years. It may also make the cleanup easier since we would only need to do it once. The main disadvantage of doing it as a single proposal is the complexity associated with changing a bunch of rules at once. We may miss some important caveat if we make the proposal too complex. Ahasuerus 19:11, 20 November 2019 (EST)

One by one with a delayed execution on cleanup if approved until the second one is also resolved? Noone says that we need to go and start cleaning up ASAP...
About the novel vs chapbook - if we decide to go with SERIAL title in a NOVEL publication, we will need software changes:
  • EditPub, ClonePub and Import will need to allow a novel with reference title as a serial
  • The show pub will will need to be updated to account for the serial as a reference title.
  • Probably some things I had not thought of...
And then we are getting into the counting conversation again - if a book is split into 4 80-pages chunks, are those chapbooks or novels? What of it is in 2 130 pages one and one last 40 pages one? 3 110 pages ones? Where do we draw the line between a chapbook and a novel as Serial publications and who is going to do the counting? While with novella/novel it makes a difference, with the split novels, it really does not matter for anything anyway. Using the same container for every serial will clear all that out. And we already use chapbooks for serials. So... :)
If the problem is the name, we can always rename that to "ISFDB container" and be done with it... Annie 21:57, 20 November 2019 (EST)

Linking to outside websites

Has there been any progress in allowing ISFDB publication records to be directly linked to other websites? Mhhutchins|talk 15:24, 16 November 2019 (EST)

FR 957, Add a repeatable "Web Pages" field to Publication records, was discussed in late 2016 and had broad support. It hasn't been implemented yet. Ahasuerus 15:43, 16 November 2019 (EST)
I would think that if you want this database to be a resource for people other than those who edit it that making linkable records would be a priority. Mhhutchins|talk 02:25, 21 November 2019 (EST)

Help page update: Chapbooks and Serials

When we allowed the SERIALS to be the fiction piece of a chapbook (See the changes log, we updated all explanations of what a Serial is but not of what a chapbook is. The places I can find are:

Did I miss any? We need to add SERIAL to the SHORTSTORY and POEM in these write-ups. Any other places or any concerns? Annie 15:16, 17 November 2019 (EST)

There is also Help:How to convert a novel to a chapbook. It needs to have POEMs added and generally cleaned up. Ahasuerus 17:18, 17 November 2019 (EST)
Ah, yes. The page that also says "If a publication has been primary verified, it should normally not be converted from NOVEL to CHAPBOOK without consulting, or at least informing, the primary verifier.". A part ignored way too often. (and moderator note would be enough of a notification as there is always at least one EditPub needed). While we are changing this page, should we add this as a viable notification method for that in the relevant sections and in the warnings at the bottom? Annie 18:01, 17 November 2019 (EST)
That page looks like it could use a lot of TLC. It was created a long time ago and a lot has changed since then. It's probably better to clean everything up and re-evaluate afterwards. When I was upgrading other old Help pages 1-2 years ago, I found that so much got changed or dropped in the process that it made sense to wait until the end of the cleanup phase before adding anything new. Ahasuerus 19:27, 17 November 2019 (EST)

(unindent) Basic cleanup done; references to POEMs and SERIALs added where appropriate. Ahasuerus 17:42, 19 November 2019 (EST)

Night's Dawn Trilogy (paperback) series

Can someone look at this one. Why do we have it as separate title series when all the contents are the half novels of the main series? It is just the format that is different - the first 2 are the complete first novel and so on - they are not split in different places? How is that different from the French translating a novel into 2 volumes? And if the first volume from the main series is printed in 2 volumes in Russian (matching the paperback release series) and the second in 3 (splitting differently and using the original as a base), where do the translations get connected? In different series? Or in the main one even if the first volume matches the split of the second series?

Under the current practice, they should have been varianted to the full novels (as we do for split translations) - the way they are done here not only splits the whole series weirdly but also loses the connections between the different works and also introduces a third way to record a split novel. So why do we have it this way? Does anyone remember? I will be pinging all the active PVs as well to see if any of them has an idea as well.

I really do not like varianting half novels to the full novel with both still being novels but this is what we do. Just because these are in English does not make the rule different, does it? Or am I missing something? :) Annie 16:35, 17 November 2019 (EST)

It turns out that there is at least one other series that uses a similar approach -- see Woman of the Iron People and its "(split paperback edition)" sub-series. I don't know for sure, but I suspect that the editors who originally organized these series wanted to avoid using VTs. Regardless of their motivation, I don't think it's the correct approach under the current rules. In addition, using "paperback", i.e. an attribute associated with publications, to organize title records only confuses things. At one point we did it to distinguish between paper-bound and electronic versions of certain magazine runs, but it was the last resort. Ahasuerus 17:37, 17 November 2019 (EST)
There are at least a few more I suspect... The magazines are also a mess (we had a thread earlier... I need to resurrect that and really deal with the that split - especially now when we can show format in the grid) but I hoped that at least the novels are sorted out. Then I started looking... Making up your own rules that contradict the written ones (which you do not like) is so not the spirit of this project... :) I can see their point BUT if Dune, volume 1 in French, Serbian or Japanese goes under the main title, an English split goes there as well (and so is the German in the other discussion we are having). Otherwise we just make a mess of a page and noone knows what contains what... Organizing the omnibuses into their own subseries - fine. Splits? Do we make separatem series for "published in 2 parts each", "3 parts each", "4 parts each"..."12 parts each" (now that is a serial but...) :) Annie 17:51, 17 November 2019 (EST)
One more Outremer Universe. Not even a note how the one series connects to the other (1 into 2? New split?). Annie 17:55, 17 November 2019 (EST)
It looks like the "split" information was added at the title level. Ahasuerus 19:23, 17 November 2019 (EST)
Of the split volumes - which makes it more or less invisible unless you know to look for it... And if you look only on the publication level, there is no indication at all of what that is. Annie 19:38, 17 November 2019 (EST)
And there is Varney the Vampyre but someone needs to write some notes explaining what is split and why and how they connect... Annie 17:55, 17 November 2019 (EST)
My best guess is that Varney the Vampyre (Wildside split) was moved to a separate sub-series because the 5 constituent volumes had individual titles as opposed to "Varney, the Vampyre or, The Feast of Blood, Volume I", "Varney, the Vampyre or, The Feast of Blood, Volume II", etc. This is one area where allowing SERIAL title records in NOVEL publications -- as discussed above -- may help. I would suggest that we wait for the outcome of that discussion before we make any changes to the series listed above. Ahasuerus 19:23, 17 November 2019 (EST)
Agree - I am not touching any of those series and variants until we decide what we are doing.
PS: Or we can just say that SERIALS mean chapbooks regardless of lengths (instead of changing a Novel Pub to allow two types of content - one native and one SERIAL - NOVEL is a container and a type rolled into one so we do not have a NOVEL container-only to add a SERIAL to. We can change all that of course but using the chapbooks will not require code change. And counting of words in a SERIAL... Allowing SERIALs in NOVELs is... complicated :) Annie 19:38, 17 November 2019 (EST)

Simon Stålenhag: The Eletric State - "Graphic Format" or not?

I' going to enter the German edition of the extensively illustrated The Eletric State by Simon Stålenhag and wondering if it's "Graphic Format". The help says that for a "Graphic Format" it is required that "graphic material is inseparable from the text". However, in this case the text is always separated from the illustrations, but there are definitely a lot more illustrations than text (approx. 100 pages with illustrations and 42 pages with text). Do we have an unwritten rule that still makes something like this "Graphic Format", just because of the majority of pages with illustrations? If not I'd leave that checkbox off and add some information to the note.

Jens Hitspacebar 13:26, 19 November 2019 (EST)

I am not aware of anything like that. If the text is effectively unchanged even if you remove all of the illustrations, it's not a graphic novel. Ahasuerus 17:32, 19 November 2019 (EST)
I agree. Heavily illustrated books are not graphic format in my book. Otherwise half of our juvenile very young fiction will need to be marked that way. :) Annie 20:09, 19 November 2019 (EST)
That's what I thought as well, thanks for the clarification. Jens Hitspacebar 12:32, 20 November 2019 (EST)

Vladimir Colin Award

(Copied from my talk page, Stonecreek 01:58, 20 November 2019 (EST)):

Hi, I wanna add this award on Isfdb but I don't know how... Here is about a drop-down list with all of the award types known to ISFDB, but Premiul Vladimir Colin (Vladimir Colin Award) isn't on the list. Abația trilogy was received Premiul I Vladimir Colin (info here) in 2006.--Terraflorin 00:54, 20 November 2019 (EST)

I have add some information here on my user page. --Terraflorin 05:43, 20 November 2019 (EST)
Looks good to me. Probably should add it as a polled award (as this is the only way to show the top 3 properly). As for the process: It is one of the tasks we need a bureaucrat for. Ahasuerus usually gives it a few days to see if there are objections and then creates the awards if there are no issues with them. So give it a few days here for the process to work through. :) Annie 10:48, 20 November 2019 (EST)
It certainly looks like a legitimate award, but there doesn't appear to be a lot of high quality information about it online. Will we be able to identify all nominees and winners? Ahasuerus 15:28, 20 November 2019 (EST)
Any ideas/suggestions? Ahasuerus 15:37, 2 December 2019 (EST)

Misdated titles: new cleanup report needed

Under the current rules, there is only one case where we will have a title dated earlier than its oldest publication (when the title has a publication attached to it (this will exclude all parent titles with no pubs for now) - when we do not have this first publication in the DB.

Technically, in this case adding that first publication is always the best solution although there may be a case where we may want to just note it.

Can we have a new cleanup report so we can start clearing these misdated titles from the DB? As I expect a pretty big number and a lot of work on the text types (novels and stories and essays first publications missing), maybe we should start with the two art types - these should never pre-date their publications. Then slowly add the text ones (with ignore being possible if we decide that we can have a text title here dated per first publication but not add the first publication.) Thoughts? Annie 15:11, 21 November 2019 (EST)

I agree. That would be a better cleanup report than the one I was thinking about (variant dated on the same date as the original). Ignore is indeed necessary. A lot of titles will have a title note explaining where and when the title was first published, and for various reasons the publication can not (yet) be in the database (think of fanzines, newspapers etc.) --Willem 15:31, 21 November 2019 (EST)
This one will also be catching things like: Book added before publication and then delayed - and whoever fixed the pub forgot about the titles (especially the coverart one). Or a non-existing edition is deleted from the DB but dates on the titles remaining were not adjusted. Or interior art dated with the date of the original cover it represents. Unmerges where one does not pay attention to the resulting dates (pulling the first edition out will leave both the new and the old title with the same date). And so on. Mistakes happen. It will help us solve the immediate known issue with the misdated variants (both from the coverarts rules misunderstanding and the non-fixed ones from the very old "record variants with the date of the original" days but it will also be useful long term. :)
Once we get these sorted, we can think on the "titles with no pubs which do not have variants (which are excluded from the "titles with no pubs" report) :) Annie 15:51, 21 November 2019 (EST)
Checking the database, I see 4,534 COVERART titles whose 4-digit years are before the 4-digit years of their first publication date. There are another 10,000-ish COVERART titles whose 4-digit years match, but the months/days are before the first publication date. Many of them are presumably dates with no month/day information, so the report logic will need to skip them and possibly other stuff. If we start with the 4,534 titles that are more or less straightforward, it should hopefully take care of the low-hanging fruit.
Here is what the rest of the title types look like (year mismatches only):
+--------------+--------------------+
| ANTHOLOGY    |                287 |
| COLLECTION   |                821 |
| COVERART     |               4534 |
| INTERIORART  |              22763 |
| EDITOR       |                 11 |
| ESSAY        |              10717 |
| INTERVIEW    |                455 |
| NOVEL        |               6203 |
| NONFICTION   |                327 |
| OMNIBUS      |                171 |
| POEM         |               6222 |
| REVIEW       |               1896 |
| SERIAL       |                 73 |
| SHORTFICTION |              39750 |
| CHAPBOOK     |                397 |
+--------------+--------------------+
Ahasuerus 17:02, 21 November 2019 (EST)
| EDITOR | 11 |
Can you post these 11? These are most likely editors where the date is not adjusted to 00-00 after making the yearly record. We may as well get them all cleared. The Serials should also be easy to cleanup so if you can post the Title IDs, I can take care of them. No point waiting for an official report for such small numbers. Annie 21:15, 22 November 2019 (EST)

(unindent) Sure thing. The EDITOR title IDs are:

+----------+
|   854745 |
|   522441 |
|  1421614 |
|  1565713 |
|  1571347 |
|  1591529 |
|  1839076 |
|  2006082 |
|  2073825 |
|  2454644 |
|  2599718 |
+----------+

A cursory review suggests that they are a mix of different types of issues. In the meantime, FR 1323, "Cleanup report to find titles whose dates are before the first pub date", has been created. Ahasuerus 10:40, 23 November 2019 (EST)

Link Publication pages back to the submission which created the publication record

It occurs to me that it should be very easy to add a "View original submission" link on Publication pages. The link would take you to the submission which created the displayed Publication record. I can't really think of a reason not to do it, but there are a few caveats to keep in mind:

  • The link would only be available for publications created after 2016-10-24, the date when we started capturing this information in the database
  • Only the original submission would be linked; other submissions which have affected the displayed publication since it was created would not be linked because the linking data is currently not available

Also, I wonder if we may want to display the proposed link only if the user is logged in. For casual users without ISFDB accounts it may be meaningless clutter.

What do you think? Ahasuerus 17:42, 21 November 2019 (EST)

I vote for showing it only for logged in users (and even making it a preference at some point even for logged in users).
Even if we do not have the complete history of the publication, knowing the original editor (and the original handling moderator - as view_submission has that as well) gives you two (or one...) name(s) of people that had done some research on the book to ask questions to. Plus all the notes the original submission had for the moderators. And we already can find that in the Recent Edits anyway - it just will take a long time to find it. :) Annie 18:03, 21 November 2019 (EST)
So the original submission link should show the original information? Not the current value of the fields like the current changed pubs report does? I would still see value to showing a history page of all edits (even if the edits only show the current information). Sometimes I want to know who last changed a pub and trying to work back through the edit history is a pain. -- JLaTondre (talk) 18:54, 21 November 2019 (EST)
Here is an example of what is in the "First" submission. Since then, the external ID had been shifted and the number of pages cleaned. So if I am reading your question correctly then yes, we will see exactly what was submitted in that initial call. The Edit ones are tricky (as we do not save status) but the creation ones are very useful. Annie 13:14, 22 November 2019 (EST)

(unindent) There is a significant amount of history here. Let me take a step back and cover some of it.

Ideally, we would want to have complete "Publication History" snapshots of all Publication pages available to editors. Each snapshot would display what the Publication page looked like prior to each change. It would be similar to the way Wikis let you view the history of each page. This functionality was first requested in 2006 -- see FR 43, "Edit History".

The problem with that FR is that the ISFDB database, unlike Wikis, has a lot of different types of records: titles, authors, publisher, series, etc. They are all interrelated. Changing a title record, an author record or a publisher record can change the appearance of dozens, possibly even thousands, of Publication and other pages. For this reason recreating what each Publication page looked like at various points in the past is a much bigger can of worms than what the software responsible for generating Wiki-based "history" pages has to deal with.

We have considered a number of different approaches over the years. The original approach, which Al von Ruff began implementing ca. 2007, vastly underestimated the complexity of the task. Eventually that functionality was disabled. Since then two workable approaches have been identified. The first one is to take a snapshot of the Publication page of each primary-verified publication before an Edit Publication submission affecting it is approved and save the snapshot in the database. (The reason this functionality is supposed to be limited to primary-verified publications is the amount of disk space that it takes to save the HTML of a publication display page.) These saved HTML snapshots would then be made available to editors as partial "edit history" for each PV'd publication. A certain amount of development work has been done in this area -- see SR 173 -- but much remains to be done.

The second approach is to implement FR 1238, "Create an Edit History page for publications". It's more limited in scope: it simply creates a list of "New Publication" and "Edit Publication" submissions related to each publication record. As we all know, once an ISFDB submission has been approved, the "before" state of the database is no longer available, so it's not a complete snapshot, but it's better than nothing.

The problem with the second approach is that our submission history currently stores Publication IDs in a way that makes it impossible to find them programmatically. It does, however, store newly created publication IDs in a way that makes it possible to find them easily. In order to implement the full functionality requested in FR 1238, we'll need to modify the software to store affected Publication IDs in a different way and then convert a couple million submissions currently on file. It's somewhat easier to implement than the first approach described above, but it still requires a fair amount of work.

What I am proposing here is to go after the low-hanging fruit first. We already have the ability to link each Publication page to the submission which created it. It would take no more than an hour or two of work to display links back to the originating submissions on Publication pages. It's not a whole lot, but it's better than nothing and it's something that I can realistically do even in my current state. Ahasuerus 16:35, 23 November 2019 (EST)

Anything you can provide will be appreciated as always. But it won't stop us wanting more ;-) Please don't ever take our requests, suggestions, and comments negatively. We (I believe I'm not speaking for myself) recognize that you're a volunteer as well and owe us nothing. We appreciate the work you put into keeping this site going. -- JLaTondre (talk) 10:12, 24 November 2019 (EST)
Thanks, I appreciate the understanding! If I sound frustrated at times, it's only because my productivity has been so much lower lately. Ahasuerus 08:13, 25 November 2019 (EST)

Login issues and notifications

I couldn't login to isfdb because I recorded the username I entered when I created the account, but failed to notice that isfdb had automatically changed it by capitalising the first letter. Once I realised that, I was able to login to both the wiki and the main page.

However, despite the note on the results page about a successful account creation and login:

 Login successful
 A confirmation code was sent to your e-mail address. This code is not required to log in, but you will need to provide it before enabling any e-mail-based features in the wiki.
 Welcome, Lukekendall!
 Your account has been created. Don't forget to change your ISFDB preferences.


I have not received a confirmation code - even now, about 8 hrs later. I also checked my spam folder and there was nothing from isfdb there. —The preceding unsigned comment was added by Lukekendall (talkcontribs) .

We really need to fix that wording... ISFDB does not send a confirmation code - we had been having so many issues with them that we just disabled them and the only mail-based function we have is the ability to send a mail to another editor who also has a mail anyway :) You are all set to start editing. You already have access to the DB (you will not see the changes immediately because we are a moderated system -- so a moderator needs to approve your request (and work with you if there are issues) and you can post on any Talk page in the wiki. Posting on non-wiki pages (such as your own wiki page) requires you to first have a few posts on Talk pages (anti-spam measures). Welcome to the DB! Annie 10:50, 22 November 2019 (EST)
Thanks, Annie, understood! Lukekendall 07:21, 23 November 2019 (EST)
Checking the software, I see that the misleading notification is displayed by the Wiki software. Unlike the core ISFDB software, which we have full control over, our Wiki software is a third party program. I am not an expert, but I'll take a closer look to see if the message can be customized. Ahasuerus 00:10, 2 December 2019 (EST)

Novellas and serialization in chapbooks

The split novel rule we are talking about up higher is just for novels. But we do have split novellas as well. Any reason/rule that stops us from actually treating these as proper serials even if they are not in a magazine? Here is an example - if this is a novel, this would have been the correct way to do it. Or what do we want to do here? Thoughts? Annie 11:58, 22 November 2019 (EST)

I think novellas serialized in multiple CHAPBOOK publications should be treated like novels: individual "segments" should be entered as SERIALs.
As an aside, the linked book is available online. After converting the HTML to TXT, I see that the word count is 72,890, so it's a NOVEL according to our rules. As we discussed a few years ago, the Russian word повесть (povest') doesn't map neatly onto the English word "novella". In modern Russian it's mostly (although not exclusively) used to indicate that the work's structure is not as complex as that of a typical novel. Hence 80,000-word and even 100+K-word "povests", which we would treat as NOVELs for our purposes. Ahasuerus 12:25, 22 November 2019 (EST)
Well, novels segments are now novels, not SERIALS :) But I got your point.
As for the Russian "повесть" vs "роман"... We will have the same problem across the whole Eastern block and we are adding a lot more of them lately. The definition of these never included length. And Russian also has "новелла" (novella) which is synonymous with a short story actually :) But we are now going into the counting game again and in an even harder case because of the alphabet.
I will be more than happy to convert that one to a novel (it was on my list to check - 300 pages on that first edition did look a bit too long for a novella) - but we probably need a better way to determine that. International projects are fun, aren't they? Annie 12:53, 22 November 2019 (EST)

Thanksgiving holiday in the US

This week (on Thursday) is the Thanksgiving holiday in the US, so people (like me) might be slower to respond than usual. Then there's Black Friday, where insane people go crazier trying to find great deals at stores on Friday (I generally avoid this one). So, patience all around. (^_^) ···日本穣 · 投稿 · Talk to Nihonjoe 16:58, 25 November 2019 (EST)

Adding the Australian national library as an External ID and a template

An editor mentioned it and I went digging. They do have a persistent identifier (https://nla.gov.au/nla.cat-vn6978328 for example where the ID is 6978328 (https://catalogue.nla.gov.au/Record/6978328 also seems permanent but if you click on permanent link, you get the above so we probably should go for it). So can we add it? Annie 21:11, 25 November 2019 (EST)

I would support that. ···日本穣 · 投稿 · Talk to Nihonjoe 12:18, 27 November 2019 (EST)
I have poked around a bit and the IDs do look stable. I see no reason not to add them, but I seem to (vaguely) recall that we had this discussion a few years ago and it petered out. I've had no luck finding the discussion using Google Search. Would anyone happen to remember any details? Ahasuerus 12:20, 27 November 2019 (EST)
I have vague memories about discussing and deciding not to add it in the first batch due to the relatively low number of entries we had in the system and the much bigger fish we had still standing. Will see if I can find the thread later today. Considering that we have the British and US equivalents and we are an English language site, I’d say that even if we have only a few, we need it. And maybe that will drive more books from down under into the DB. That makes me wonder about the CAnadian library. :) Annie 13:33, 27 November 2019 (EST)
OK, if there are no objections, I will create the new External ID/template pair in a couple of days. Ahasuerus 16:20, 27 November 2019 (EST)
FR 1324 has been created. Ahasuerus 12:41, 30 November 2019 (EST)
Done. Ahasuerus 15:36, 2 December 2019 (EST)
Thanks! We have 71 links with the Record format and one with the cat-vn one which I will move probably next weekend. We also have some links to NLA that lead to a page that requires a user to be logged in so I will look at all NLA references we have and clean them up (and probably come and ask if I cannot). Annie 16:32, 2 December 2019 (EST)
Can we rename that from ANL to NLA? It is usually referred to that way. Not critical but may be good to match how people look for it... :) Annie 17:09, 2 December 2019 (EST)
Done! Sorry about that, my bad. I have also added the new templatw to Help:Using Templates and HTML in Note Fields. Ahasuerus 19:00, 2 December 2019 (EST)

Del Rey Ballantine

Six publications are using Del Rey/Ballantine. As there's no note explaining why that publisher exists I suspect they are in error and should have been using Del Rey / Ballantine? --Marc Kupper 23:05, 26 November 2019 (EST)

I’d agree. We have only 2 PVs there so I would say to just leave them a note and fix that. Annie 23:22, 26 November 2019 (EST)
Thanks - plus I ran across Template:PublicationFields:Publisher which says "The things we want to avoid are the Imprint/Publisher (with no space) ..." --Marc Kupper 16:37, 27 November 2019 (EST)
Yep. If there is a reason, there should be a note explaining why. This seems like an oversight. Annie 17:53, 27 November 2019 (EST)

French Perry Rhodan series

I have a question about the French Perry Rhodan series, for example Rhodan renie Rhodan. Isn't this an omnibus, when two German titles Guckys große Stunde and Atlan in Not are put together in one pub? --Zapp 15:01, 28 November 2019 (EST)

Collection or an anthology (depending on the authors) actually because the originals are novellas and not novels. But yeah - this looks weird - if these are indeed the same texts, these should have been added as collections - the same way every Foundation out there is a collection despite what national publishers may think. I wonder if the German ones were not novels before (I remember a lot of those being converted a few years ago) and the French ones were never changed (and were added as novels based on the split novel rules (in reverse) - which say that part of a novel is a novel - still weird reading of the rules but at least it makes some sense). Linguist is around - so why don't you post on his page and see what he knows about this? Annie 15:17, 28 November 2019 (EST)
Hi. Hauck had devised this "Perry Rhodan in French" series, on the ground that at a certain time, Fleuve Noir started compiling two original episodes in one volume (usually novellas), presented as a single novel. Sometimes the novels are divided into two parts with individual subtitles, but sometimes not, and in this case there is no visible separation between the two episodes, and of course no French titles to variant to the German ones (this is usually indicated in the notes). Hence his choice, which I went along with. It is true that it is annoying not to be able to link the French translations to their originals, but there it is. Making collections or anthologies of them (and varianting the parts) would be possible for some, but not for all of them, which I think would wreak havoc in the series if it were attempted. But someone might have a bright idea to solve the problem… :o) Linguist 05:24, 30 November 2019 (EST).
Part of the problem also seems to be that Darlton & Scheer are credited as authors / editors and not the actual authors of the respective novellas, or are they somewhere in the volumes? Christian Stonecreek 12:09, 30 November 2019 (EST)
It would be in theory possible to identify the beginning sentences of the respective novellas, enter them (likely as by 'uncredited'), and then variant them to their parent titles, but I think you'd need both the originals and the French publications for that. And it still seems possible that the latter are in fact fix-ups with linking material by the French editor(s), analogous to the work done here. Christian Stonecreek 05:51, 1 December 2019 (EST)
Late editions do credit the actual authors (particularly after Presses Pocket took over the series), but this doesn't solve any problem : take Projet Basis and La déesse endormie for instance : they correspond to the first and second half of Perry Rhodan Silberband #101, i.e. Eiswind der Zeit, revised version by Hubert Haensel of 10 German episodes individually credited on copyright pages to H. G. Ewers, Kurt Mahr, Hans Kneifel, Clark Darlton or H. G. Francis. The first French volume is just divided into 16 chapters, and no individual titles. The second one has 13 chapters, with five subtitles corresponding to the titles of the original German novellas : so from one book to the other, the presentation is different, and makes systematic varianting to original titles and crediting to real authors impossible. Ein echtes Durcheinander ! Linguist 05:54, 1 December 2019 (EST).
Well, no doubt about that! At least for the moment, for me also it seems best to leave the series as it is. Christian Stonecreek 06:33, 1 December 2019 (EST)
Or we can fix at least the ones where the separation is there and clear enough. While that won't catch everything, it will catch the ones we can catch and be more consistent with the intent of the DB. Not sure how easy that would be if we do not have access to a lot of the issues though... Annie 06:44, 1 December 2019 (EST)

Wording of text printed by "Incomplete" template

It just occurred to me that the text "Contents incomplete" printed by the "Incomplete" template could be ambiguous for some users: it can be interpreted as "contents in the publication are incomplete" (e.g. a misprint) or as intended as "contents in the database not completely entered yet". Shouldn't the wording be expanded a bit to make it's meaning clearer? E.g.: "Contents of this ISFDB record are incomplete" Jens Hitspacebar 10:47, 30 November 2019 (EST)

I may be having a slow evening (or morning...) but what would "contents of the publication itself is incomplete"? Contents table? Something else? Annie 06:02, 1 December 2019 (EST)
What I mean is that, for a casual user who doesn't research our wiki for more information about it, the phrase "Contents incomplete" could refer to either the database record or the book. We, as editors, know what we mean: the database record is incomplete. But a casual user reading this phrase might think that we mean the book instead and then ask himself "aha! But what is incomplete in the book? The contents table, or what?" or "is it a misprint, or what in the book is incomplete". In short: the phrase ambiguous. Jens Hitspacebar 08:41, 1 December 2019 (EST)
<light bulb> I think I see what you are referring to. I remember Keith Laumer once complaining about his Swedish publisher "abridging" one of his novels by dropping the last couple of chapters. I also recall a magazine editor dropping the ending of one of Philip K. Dick's novels. And, of course, printers occasionally screw up, which results in missing pages in the final product. Is that what you mean? Ahasuerus 15:46, 2 December 2019 (EST)
This makes sense (Bard did the same to Zelazny's "Lord of Light" first Bulgarian edition - they 'forgot' to print the last chapter). And now that you pointed it out, I can see how "Contents incomplete" can be read that way as well. Maybe we should go even further than that: "The contents of this ISFDB record is incomplete and additional eligible content still need to be added". Or words to that effect (proving again that templates are good things) :) Annie 16:43, 2 December 2019 (EST)
Yes, that's what I was referring to, especially the "printers occasionally screw up" part :) I hadn't thought about abridgements yet, but now as you mention it: yes, that's also a way to "misinterpret" the "Contents incomplete" phrase. Actually, extensive abridgements of translations were very common in German SF publishing at least until the late 1970s. It's quite possible that some users assume that "Contents incomplete" refers to these abridgements. Jens Hitspacebar 18:32, 2 December 2019 (EST)
OK, we are on the same page then.
Re: Annie's suggestion, I think "additional eligible content[s] still need to be added" would be too limiting since the "Incomplete" template may be used when we have no plans to add more titles, e.g. when entering a non-genre anthology. Something like "This publication contains additional titles which have not been entered into the ISFDB database" would be hopefully generic enough to cover all possible permutations. Ahasuerus 16:18, 3 December 2019 (EST)
I disagree. So did you a few weeks ago. See this and FR 1309. We specifically created this template for cases where we still want to add more contents. We need another one for the non-genre things - mixing the two makes this one useless (the whole point of having it is to ensure that we can find the magazines/anthologies that NEED more contents. Annie 16:24, 3 December 2019 (EST)
I agree with Annie. The template's help states that is is "to be used in publication notes to indicate that not all eligible title records have been entered yet. Not supposed to be used if ineligible (typically non-genre) titles are intentionally excluded." Her proposal for the template's text is good. A new, different template for omitted non-genre titles, e.g. {{IneligibleContentOmitted}}, is a good idea. Jens Hitspacebar 16:38, 3 December 2019 (EST)
Oh, I see. Sorry, I was confused. I'll go along with Annie's suggestion then, perhaps modifying the wording a bit, e.g. "The contents of this ISFDB record are incomplete; additional eligible titles still need to be added". Ahasuerus 17:13, 3 December 2019 (EST)
Massage away -- it was first attempt at saying what would make the most sense. Maybe "contents listed in this" instead of "contents of this"? So it is clear we are talking about the contents below. Or am I overthinking it? :) Annie 18:05, 3 December 2019 (EST)
Something concise and explicit like "The Contents section is incomplete; additional eligible titles still need to be added"? Ahasuerus 20:11, 3 December 2019 (EST)
Is that unambiguous enough to ensure that it is clear we are talking about our contents section and not the book's? Maybe insert "below" after section? Or "of this record"? Annie 20:42, 3 December 2019 (EST)
I like "below". And, as you said, we can always change the wording again because it's a template. Ahasuerus 23:18, 3 December 2019 (EST)
There should definitely something like "below" or "of this record" in the wording, otherwise "The Contents section" would still be a bit ambiguous, because it could still be interpreted as referring to the book's contents section I'd prefer "of this record" because, unlike "below", it doesn't create a "dependency" to how notes and contents are displayed. If the display of the notes and contents ever gets a massive redesign, or an app is created, "below" could become the wrong hint if the template's wording is forgotten to be adjusted as well. But as that'd be easy to fix I'm fine with "below" as well :) Jens Hitspacebar 03:39, 4 December 2019 (EST)
OK, I see what the problem is. Let's go with "The Contents section of this record is incomplete; additional eligible titles still need to be added" them. Ahasuerus 11:17, 4 December 2019 (EST)
Sounds good. Jens Hitspacebar 13:39, 4 December 2019 (EST)
FR 1325 "Change the wording of the 'Incomplete' template" has been created. Ahasuerus 16:44, 4 December 2019 (EST)

Rudimentary "Edit History" implemented

As per this discussion, a rudimentary "Edit History" system has been implemented. At this time it is limited to submissions which have created new publication records since 2016-10-25. Publication pages have been modified to display "[Edit History]" links which take you to the new "Publication History" page. Note that only publication records have been affected and that only NewPub, AddPub and ClonePub submissions are currently displayed. It's not much, but it should help in certain cases. Ahasuerus 20:37, 1 December 2019 (EST)

Thanks - that can come handy when chasing why some things look the way they do :) Annie 01:14, 2 December 2019 (EST)

Titles and images for interior art

I've acquired a number of art books/calendars for artists of record on ISFDB and was checking to see if they were used for covers. For calendar matches, I simply added a note to the title record for the cover. Then I noticed that some interior images were given titles not in the book, and multiple publications used the same interior image title record. I presume someone had access to both books, but for someone working from a single book, the naming would be impossible without stored images for the artist.

Some interior images are stored (e.g. Map of Compact Space) although I suspect such usage is obscure. What is the current stand on ISFDB's ability and desire to store interior art images? (I'm not looking for a change, just a statement/comment, since searches of the Help provide little information beyond mention of the example above.)

P.S. Actually searching such images to find a match for an image in hand would have been unthinkable when we first started loading images, but given what Facebook (and others) are doing, it may not be long before someone could upload an image and search for matches. But I digress. ../Doug H 23:10, 1 December 2019 (EST)

As an aside on the last paragraph: Well, Google has Image search which accepts either a link or an uploaded image. And occasionally it does help with the identification of uncredited covers for me (enough to know where to look to find the original anyway). Annie 01:12, 2 December 2019 (EST)
To be more specific in my imaginings - an editor could upload a cover/interior art image and have the ISFDB software provide possible variants / merges. Anyway, not my main point. ../Doug H 10:10, 2 December 2019 (EST)
Yeah, and when I posted, the Note in acknowledging that this is a side comment stated only in the header of the message. On the main topic, I remember some concerns about copyright cited as a reason not to host too many of them but need to do some digging to find the threads. Annie 10:19, 2 December 2019 (EST)
Checking the database, I see that only one INTERIORART title (The Clewiston Test) currently has a "Webpages" link that takes you to an ISFDB-hosted image. And even that is only due to the fact that it's a back cover image.
Like Annie, I believe I recall discussions of copyright issues related to hosting scans of interior art. I don't remember all the arguments, but I think it was a gray area. I would be leery of uploading interior art scans until we have a better understanding of the issues involved. Ahasuerus 15:01, 2 December 2019 (EST)

In which I die at the end...

Personally speaking, I reserve a special place in hell for authors of those first-person stories (both short and novel length) in which nothing genre happens for the entire length, only to discover in the last paragraph that it has been narrated by a dead person. The story itself has been entirely non-genre from start to finish but this twist, for good or bad, changes everything. In or out? PeteYoung 07:21, 2 December 2019 (EST)

There are a number of variations on this theme. Sometimes it's reversed: the story appears to be SF, but in the end we discover that "it was all a dream". Alternatively, the narrator turns out to be a dog or another animal.
Typically, I include these borderline/"twist" stories and add a Note about any irregularities. Admittedly, doing it without spoilers can be a challenge. Ahasuerus 09:00, 2 December 2019 (EST)
I expect that an historical novel written in the first person would be non-genre, even if that perspective was a post-death recollection of events. So I don't think the mere fact it is narrated by a dead person makes it eligible. Regarding the "all a dream" situation, it is still fantasy writing regardless of the 'reality' of the fantasy. As for the animal narrators, if it's just to provide a narrative perspective, I'd say out. The degree of participation and analysis of the narrating animal would be the variable factor. ../Doug H 10:25, 2 December 2019 (EST)
Those and the Outlander-light and/or reverse romances (where the only speculative thing is that one of the heroes get dumped into a different time) and the "well, he is a fairy but lives as a human except that his house is never cold (or something)" novels always give me a headache. Technically they are genre. The one where the person narrating is actually dead and is narrating from an afterlife is even closer to the border than the romances... If the story is setting up the stage for a continuation where being dead (and/or a ghost) is important, I would add it. If not and it is a book I am adding... I will probably pretend the last line is not there (or that it was a diary or something) - so not eligible and skip it. If an editor adds it, it is technically eligible...
Pete, do you have an example? We can look to see where it is categorized in a library system maybe (as a guide of how people see the novel)? Annie 16:56, 2 December 2019 (EST)
I read a short story a couple of days ago in the anthology Singapore Noir, currently not indexed, which is what triggered my question: the narrator gets thrown off a skyscraper balcony to a certain death. A couple of others I can recall are Derek Raymond's novel A State of Denmark, which is certainly genre anyway, and Shan Sa's 2004 historical novel The Girl Who Played Go which we currently don't have in the db. It's the one I'm primarily considering. I'm inclined to agree with Doug because it's really a novel the db can do without, and I can't find commentary anywhere that remotely describes this novel as genre. To add a note that would read something like "Non-genre until the last chapter" doesn't really cut it for me unless there is a more fantastical twist that just 'the afterlife'. PeteYoung 07:12, 3 December 2019 (EST)
Then leave it out :) If another editor feels very strongly about it being genre or it starts showing up in our anthologies or become the start of a genre series or something along these lines, it will come back and get added later. Annie 11:11, 3 December 2019 (EST)

Moderator note on Publisher Edit

Can we add "Moderator Note" in the editpublisher page? And any other that does not have it but that is the only one I can think of now... Annie 15:30, 4 December 2019 (EST)

I support this idea. ···日本穣 · 投稿 · Talk to Nihonjoe 16:31, 4 December 2019 (EST)
I must have missed it back when I was adding the Moderator Note field to Edit pages. FR 1326 has been created. Thanks! Ahasuerus 16:47, 4 December 2019 (EST)

Clarkesworld - merging the two separate series

I want to merge the Clarkesworld (print issues) and Clarkesworld Magazine series (merging the Editors under them). The issues have the same contents, the only difference is the format and the grid now shows the uncommon formats so it will be clear what is what... Plus it won't look as if we are missing an issue altogether when we have it in only one of the formats (and now that we can clone magazines, people can clone for the other formats instead of doing all the work because they did not realize the issue is actually already in). Does anyone see a reason why not? Annie 17:00, 4 December 2019 (EST)

Personal tools