ISFDB:Community Portal/Archive/Archive37

From ISFDB
Jump to navigation Jump to search

This is an archive page for the Community Portal. Please do not edit the contents. To start a new discussion, please click here.
This archive includes discussions from

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 · 48 · 49 · 50 · 51 · 52 · 53 · 54 · 55


Archives of the community portal for May - September 2015

Proposal: change name of field 'familyname' into 'sortingname'

As the field 'familyname' is only used for sorting and sorting -at least in the Netherlands- is not done on the complete family name, can we please change the name of the field to sorting name? It is less confusing that way.--Dirk P Broer 16:33, 29 May 2015 (UTC)

I've stated the same thing in the past, but it never got anywhere. I don't believe many users (or editors for that fact) are even aware of the purpose of this field. Other than the editing mode, it's never displayed in an author's summary. By changing the name of the field in edit mode, at least it will make clear the field's purpose. (Of course, I may be wrong and the field is used for something else. If so, I'm curious to find out.) 18:05, 29 May 2015 (UTC)
No, it's only used for sorting purposes. At one point we changed the name of this field from "Last name" to "Family name", which was more accurate, but I agree that "Sorting" is even better -- FR 806 has been created. Ahasuerus 18:33, 29 May 2015 (UTC)
I agree with this. This change would avoid puzzling over the real purpose of the field. Linguist 08:28, 31 May 2015 (UTC).
I like this idea, as well. ···日本穣 · 投稿 · Talk to Nihonjoe 02:34, 1 June 2015 (UTC)
I recommend "Collation" over "Sorting" since it is more general and could be extended to other types of "sorts". Uzume 16:56, 2 August 2015 (UTC)
It may be a more accurate term, but my concern is that some users may be unsure what "collation" means in this context. Ahasuerus 18:30, 2 August 2015 (UTC)
In this context, I have no idea what "collation" means. I can't see anyone confusing "sorting". Mhhutchins 00:53, 3 August 2015 (UTC)
Basically, "sorting". I also prefer "sortingname". ···日本穣 · 投稿 · Talk to Nihonjoe 01:20, 3 August 2015 (UTC)
I'm all for “sorting” as well. “Collation” might be a bit too vague and indeed, puzzling (just realized I had already responded to this). Linguist 08:18, 3 August 2015 (UTC).
I am not going to argue if there is consensus but I am not sure what else "collation" could mean in this context (it basically just means "ordering" and we are talking about a number of different possible orderings based on language, etc.). Uzume 22:16, 8 August 2015 (UTC)
To use 'Sorting' seems to me to be the best approach. Stonecreek 05:08, 9 August 2015 (UTC)
"Sorting" it is then! Ahasuerus 07:05, 9 August 2015 (UTC)

Dream Park series by Larry Niven and Steven Barnes

I've seen a few places around the net which indicated The Descent of Anansi is part of the Dream Park series. I have not read the book, or the others in the series, so I don't know if they are related. Anyone here read them and know? ···日本穣 · 投稿 · Talk to Nihonjoe 23:45, 2 June 2015 (UTC)

According to Wikipedia "The Anansi incident, Falling Angel, and other elements of the story are used as background in the Dream Park series, particularly The Barsoom Project, the second of the series." But SFE3 doesn't include this title in any series. I would suggest not placing it directly into the Dream Park series, but perhaps you could create a universe series containing both this title and the Dream Park series as a subseries. I have no idea what you could name this universe. Maybe someone whose read both can come up with one. Mhhutchins 00:11, 3 June 2015 (UTC)
If nothing else, we can call it the Dream Park Universe. ···日本穣 · 投稿 · Talk to Nihonjoe 03:59, 3 June 2015 (UTC)
Okay, I've created the Dream Park Universe and put the Dream Park series, Fallen Angels, and The Descent of Anansi into it. It's waiting for approval now. ···日本穣 · 投稿 · Talk to Nihonjoe 00:53, 5 July 2015 (UTC)
Approved, thanks! Ahasuerus 03:23, 5 July 2015 (UTC)

Other Title Types Ranked by Awards and Nominations fixed

Bug 577 (Other Title Types Ranked by Awards and Nominations list errors out) has been fixed. Ahasuerus 00:08, 10 July 2015 (UTC)

"Duplicate Finder matches CHAPBOOK and SERIAL titles" fixed

Bug 576 (Duplicate Finder matches CHAPBOOK and SERIAL titles) has been fixed. Ahasuerus 01:39, 10 July 2015 (UTC)

My ISFDB development instance

I extended my own ISFDB instance by some more features which I would like to have (see two examples above). I now described what I currently do in my user page User_talk:Stoecker#Own_ISFDB_instance in case someone wants to use it. Patches are supplied together with this description in case main ISFDB code maintainers decide to apply them. --Stoecker 19:05, 10 July 2015 (UTC)

Thanks for the update! Normally, the development process calls for a Wiki discussion first. However, since the work has already been done and since everybody can see the results, we can use this Wiki page to discuss whether the new functionality is desirable and, if it is, whether we need to tweak anything before it's implemented on the main server. Ahasuerus 04:13, 11 July 2015 (UTC)
I implement what I need. Whether discussion at ISFDB decides to use that or not is independent from that. It would be fine, but if not or until implemented I have what I need. E.g. the duplicate cover finder: I permanently use it and submitted maybe 100 or more cover variants. An Implementation in ISFDB would be better, but it's not required. --Stoecker 16:49, 11 July 2015 (UTC)
Let's start with change #3 since it's fairly straightforward. As far as I can tell, this software modification added three "modes" to the "My Primary Verifications" page. The modes are listed at the top of the page.
  • If you choose the "No Cover" mode, the software behavior is apparently the same as it has been for the last year+.
  • If you choose the "Cover Info" mode, a new column, "Cover", appears on the right. The column contains the word "cover" (color-coded) if there is a cover associated with the publication. If there is no cover, the cell is left empty. The column also displays an asterisk next to the word "cover" if the associated cover title is a variant of another cover title.
  • If you choose the "Full cover" mode, the behavior is similar to the "Cover Info" mode except that the word "cover" is replaced with a thumbnail version of the actual cover. The asterisk functionality is the same as described above.
Is this an accurate summary? If it is, then I expect that the "Cover Info" mode can be useful when trying to identify incompletely verified pubs. (I haven't done much work on the verification side over the last few years, so I will defer to other editors.) However, the use of asterisks doesn't seem intuitive in this case, so I wonder if it might be better to add another column for "Variant Cover?" and display a check mark if it is. Ahasuerus 04:13, 11 July 2015 (UTC)
Yes - the asterisks is unintuitive (but mouseover showing the target title helps a bit). But a new column would waste too much space and most people probable don't care whether it's a varianted title or not. My philosophy is that not every feature must be documented or obvious - if people don't find the idea behind, then they probably don't need it. --Stoecker 16:49, 11 July 2015 (UTC)
As far as the "Full cover" mode goes, I am not sure how often editors would use it. It takes about a minute to load <1,000 covers with my 25Mbps connection, which is a long time in this day and age. Ahasuerus 04:13, 11 July 2015 (UTC)
All this is probably very nice but, in my case, strictly useless (I've got all the covers of my books and the mass of data is a bit too large) but this should not deter from implementation. Hauck 17:14, 11 July 2015 (UTC)
As the server load is the same and implementation is primitive this is something the editors can decide. I myself want it to see the covers of my pubs. Regarding speed - page is completely loaded, only the pics are delayed. --Stoecker 16:49, 11 July 2015 (UTC)
Well, the actual behavior depends on the browser. My version of Firefox is somewhat unhappy and becomes jerky when there are that many images to load. Also, since many images are hosted/served by the ISFDB server, it could conceivably cause bandwidth issues.
It looks like the easiest thing to do would be to make the functionality of the "Cover info" mode the default behavior and then we wouldn't need to support multiple modes. Ahasuerus 08:08, 12 July 2015 (UTC)

(unindent) Based on the discussion above, the My Primary Verifications page has been changed to display each pub's artists and a link to the pub's cover image. Please note that, unlike Dirk's original implementation which color-coded cover links, the current implementation displays "ISFDB", "Amazon" or "other" in the "Cover" column. If everything looks OK, we can discuss whether we need to indicate that the COVER title associated with a pub's image is a variant. Ahasuerus 23:31, 12 July 2015 (UTC)

Trying to figure out who this artist is - And All Between by Zilpha Keatley Snyder

And-All-Between-signature-for-artist-unknown.jpg

This is a closeup of the signature on the cover of 2609 this book. Anyone know who the artist is? ···日本穣 · 投稿 · Talk to Nihonjoe 18:07, 11 July 2015 (UTC)

The link is incorrect... you mean this cover. No idea on the artist, though. PeteYoung 22:08, 11 July 2015 (UTC)
Weird. Fixed now. ···日本穣 · 投稿 · Talk to Nihonjoe 02:31, 12 July 2015 (UTC)

A Wizard in Absentia

According to ISFDB, A Wizard in Absentia is part (#3) of the Rogue Wizard series by Christopher Stasheff. However, according to every list of his books at the beginning of various books in the main Warlock in Spite of Himself (and subseries), this book is actually the first in the Warlock's Heirs series. Was this just accidentally added to the wrong series due to the name of the book? Just trying to sort things out. ···日本穣 · 投稿 · Talk to Nihonjoe 05:59, 12 July 2015 (UTC)

We had this discussion 5 years ago, but it looks like it was inconclusive. Ahasuerus 08:00, 12 July 2015 (UTC)
I also noticed that what the publisher has and what is on Stasheff's official page are different (and Stasheff's is different than what we have). Now I'm just all confused. :) ···日本穣 · 投稿 · Talk to Nihonjoe 15:10, 12 July 2015 (UTC)
Retconning can cause all kinds of peculiar continuity problems, up to and including "series jumping" :-) Ahasuerus
No kidding. Too bad we can't make it part of both series. ···日本穣 · 投稿 · Talk to Nihonjoe 05:16, 13 July 2015 (UTC)
That would be our old friend FR 406 :-) Ahasuerus 06:54, 13 July 2015 (UTC)
"Hello, old friend." - Sinclair. ···日本穣 · 投稿 · Talk to Nihonjoe 22:23, 14 July 2015 (UTC)

"Key Maintenance" moved

The link to "Key Maintenance" has been moved from the Editing Tools menu to "User Preferences". Ahasuerus 02:56, 15 July 2015 (UTC)

Nice, I'm always clicking on it by mistake (I don't even know what it does!). Hauck 10:01, 15 July 2015 (UTC)
You and me and probably many other editors :) Ahasuerus 12:55, 15 July 2015 (UTC)
It is basically used as an ancillary form of authentication (that was created targeting web API usage such as bots like Fixer, etc.). It is not really needed as the current cookie based method used for normal use logins could easily be used but it is still around for historic reasons (I believe the web API uses this only and as such so do the bots). Uzume 22:14, 8 August 2015 (UTC)
That's right, it's only used by robotic submissions at this time. Ahasuerus 02:18, 9 August 2015 (UTC)

Edit Title changes

The Edit Title page has been modified to allow removing "Series" and "Series number" data from CHAPBOOKs and VTs. Ahasuerus 22:03, 15 July 2015 (UTC)

Yay! ···日本穣 · 投稿 · Talk to Nihonjoe 22:47, 15 July 2015 (UTC)

Updated "Help" page on "How to record a variant title"

I deleted the last section of this help page, which was:

Note: Old Variant Format
Note: The old (ISFDB1) format indicated variant titles by including all of the titles in the title field, separated by carets, like so: "The Book of Poul Anderson^The Many Worlds of Poul Anderson". This is no longer supported for display. New data should not be entered in this format. To record variant titles, use the method described above; and please convert records in the old format as you come across them.

Justification: A search, along with testing to make sure that search would catch any such books, showed that we no longer have any such books in the system. It has been long enough since this format was used that there is no longer any editor who would "accidentally" use that format. Chavey 05:05, 18 July 2015 (UTC)

That's great! I myself have never used that system since it was before my time, but anything that will cause less confusion, the better. However, that note still exists in a few places that I know of, for instance; here on the Help-Add Variant page and here on the Help-Edit pub page and here on the Help-New pub page. Perhaps this can be dealt with at the template level and omit all instances at once, but I'm not sure if it works that way. Syzygy 22:59, 18 July 2015 (UTC)
Thanks for pointing that out. You're right, those occurrences were all from the TitleFields:Title Template, so when I correct that, all of the ones you pointed out were then corrected. Chavey 08:30, 22 July 2015 (UTC)

Bob Kruger / Robert Kruger

In a recent e-mail an MITSFS librarian suggested that Bob Kruger may be the same person as Robert Kruger. Comparing their bibliographies, I don't see a whole lot that is similar: Bob Kruger co-edited a couple of anthologies based on the Lovecraftian RPG Delta Green while Robert Kruger didn't seem to have anything to do with RPGs or Lovecraft. Would anyone happen to know otherwise? Ahasuerus 03:26, 19 July 2015 (UTC)

Bob is an acquaintance. I'll email him and ask him to check out both pages. Mhhutchins 22:47, 21 July 2015 (UTC)
Thanks! Ahasuerus 01:49, 22 July 2015 (UTC)
He's the author of all works, and the pseudonym/variants have been made. Mhhutchins 02:50, 22 July 2015 (UTC)

The Complete Robot

The Complete Robot consists of several parts with short introductory notes. One of these introductions is called "Susan Calvin". There is also an editorial by Asimov called Susan Calvin. These two essays are not identical, but it seems they were merged by mistake. I'm posting this here since it affects all editions of The Complete Robot, and thus several verifiers. Darkday 17:27, 21 July 2015 (UTC)

Fixed. Thanks for bringing this to our attention. Mhhutchins 17:04, 25 July 2015 (UTC)

A nonfiction book about a film based on a science fiction novel

Should this title be eligible for the database? Too many degrees of separation if you ask me. (Albeit, one of the finest science fiction films ever made.) Mhhutchins 15:13, 25 July 2015 (UTC)

Borderline at best, but why not? (we've got in store worst offenders). Hauck 16:24, 25 July 2015 (UTC)
And those offenders should be removed as well. This book is not speculative fiction, it is not about speculative fiction, it is not by a speculative fiction author, and it has not been reviewed in a speculative fiction publication. If it had been any one of those four, it would have qualified under the current rules. The question remains if there is substantial discussion about the sf novel upon which the film was based, and there is no clear indication of that. It appears to be a shot-by-shot discussion of Tarkovsky's film Stalker. Mhhutchins 17:04, 25 July 2015 (UTC)
<checks Google Books> The book has a fairly extensive discussion section, including a description of the process ("endless rewrites [by the Strugatsky brothers]") that led to the transmogrification of the novel into the movie, so I think it's OK to keep it. Come to think of it, this is a good example of how intertwined written SF and SF in other media can be: three (!) different versions of the "Stalker" screenplay have been published since 1981. Ahasuerus 18:15, 25 July 2015 (UTC)
EX-TER-MINATE! Hauck 18:18, 25 July 2015 (UTC)
I searched the Google Books file too and saw only three pages that reference "Strugatsky", and four pages that mention Roadside Picnic. In a 240 page book, I don't believe that would constitute a substantial discussion about the novel. Mhhutchins 18:53, 25 July 2015 (UTC)
There is no mention whatsoever among the reviews on the Amazon listing about the Strugatskys or their novel. Mhhutchins 18:55, 25 July 2015 (UTC)
According to one Goodreads reviewer (the only one that mentions the Strugatskys): "Geoff Dyer's long essay entitled Zona: A Book About a Film About a Journey to a Room. This last is in a genre by itself, an extended commentary retelling the story of the film with lengthy footnoted riffs about how the film has impacted Dyer's life and imagination." Still don't think it's eligible, but will drop the subject. (I may actually get a copy of the book since it sounds fascinating.)
BTW, every science fiction fan should see Stalker. Teaser scene https://youtu.be/s0VJa3HmsJQ Mhhutchins 19:02, 25 July 2015 (UTC)
I agree with Hauck's simple comment. We do have reviews and other nonfiction content but we do not allow graphic novels or films, etc to be cataloged here. I do not think a review of a film qualifies (even if the film itself is based on acceptable content). If we decided to include this, I would say we would need to allow reviews of graphics novels if there was acceptable related content (e.g., novels related to graphics novels or films, etc.). That seems a slipper slope that I believe we just do not need. It would be far better to just add a comment/link on the acceptable content pointing to the film or book about the film, etc. Uzume 16:37, 2 August 2015 (UTC)
All content of a speculative fiction publication is eligible for the database, regardless of its subject or genre. So if Analog publishes a science article which has nothing to do with speculative fiction, it is eligible for the database, but not the science book unless it qualifies under other criteria. If F&SF reviews a film (like Lucius Shepard's column), the review is eligible for the database. If Asimov's reviews a graphic novel (as Paul Di Filippo often does), then the review is eligible for the database, but not the graphic novel unless it qualifies under other criteria. All reviews for works which are not eligible for the database are entered as ESSAY. If a review is for a work which is eligible for the database, it is entered as a REVIEW so that it's record can be linked with its subject. The policy seems pretty straightforward with the distinctions rather clear about what is eligible. A book about a science fiction film (whose source is only tangentially mentioned) by an author who is not "above the threshold" is very clearly not eligible for the database, nothing borderline about it. Otherwise, all books about science fiction films would be eligible, and that would be a landslide, not a slippery slope. Mhhutchins 16:54, 2 August 2015 (UTC)
True, but I do not think that is a factor for this type of publication is it (is there substantial speculative fiction content in this book about the film)? Uzume 22:10, 8 August 2015 (UTC)

Development update

As some of you may recall, the software repository which we use for development purposes (SourceForge) experienced a catastrophic failure on 2015-07-16. Yesterday they announced that they expect to finish restoring all services by 2015-08-04. In addition, the company that owns SourceForge has announced that they plan to sell it.

Based on this unfortunate experience and on SourceForge's uncertain future, I am considering switching to a different repository once everything has been sorted out. Ahasuerus 21:00, 30 July 2015 (UTC)

It looks like SourceForge has become something like the "MySpace" of Open Source code repositories in recent years. They tried to catch up with new, thriving competitors like GitHub, but their improvements often felt like patchwork. If they wanna sell it now it sounds like SourceForge's death blow to me. Jens Hitspacebar 21:43, 30 July 2015 (UTC)
My thoughts exactly! Ahasuerus 22:44, 30 July 2015 (UTC)
Are you considering Git (e.g. GitHub)? Jens Hitspacebar 21:43, 30 July 2015 (UTC)
Well, GitHub is the 800lb gorilla these days, so I am definitely going to look into it. And I will also need to consider migrating from CVS, which is clearly past its price, to Git. Ahasuerus 22:44, 30 July 2015 (UTC)
Agreed. Since we are using Python I suggest migrating to Mercurial (which is also distributed like git but has better GUI/Windows support). It is what the Python (language) developers use (I consider this the strongest argument) and is much newer. It is not quite as popular as git however (so it might be an issue for hosting but we could host our own on the same server as the rest of the website; the bandwidth is minimal and should not take much that much space). Uzume 16:22, 2 August 2015 (UTC)
Thanks, I'll take a look. <insert a witticism about old dogs and new tricks here>. Ahasuerus 19:47, 3 August 2015 (UTC)
Essentially mercurial and the other distributed VCS are used only out of historical reasons by their communities. They lost competition against git. Nowadays choices are either git or svn. git is the fancy new tool, svn the easier not distributed variant. For ISFDB I'd suggest svn instead of git, much easier to switch from CVS to SVN, easier to use and the added power of git is not needed here. And you even can host the svn repository on the same server as www.isfdb.org. That's so easy, that I ask myself, why everybody is still using these external services when the have an own server already. It's as simple as approx. 10 lines added to the apache config. Hosting an own issue tracker is a bit more work thought :-) If you WANT an external platform for development GitHub is probably the best choice (they even have an SVN interface to Git :-). --Stoecker 12:10, 15 August 2015 (UTC)
Thanks for the suggestion! I will add SVN to the list of things to look into. At one point I was exposed to it, so I assume that the learning curve will not be as steep. Ahasuerus 01:03, 17 August 2015 (UTC)
Yes, SVN is a lot easier to learn than Git. I've been using it for many years now (and never looked back after I had done the switch from CVS to SVN, never) and I only started using Git about half a year ago. I'd say that if you don't need the extra features that Git offers then SVN is more than enough as a VCS. However, I currently don't know a SVN repo hoster which is nearly as good as modern Git hosters (and a quick look at the Comparison of source code hosting facilities didn't bring up any new candidates for that). Therefore, a modern, hosted Git platform which offers a VCS, issue tracking and more tools to collaborate all in one place might be the better solution. In case you need some general starting points, these two are pretty comprehensive, free online books: ProGit and SVN-Book. Jens Hitspacebar 20:09, 17 August 2015 (UTC)

The Mutant Weapon vs. Med Service

Dirk P Broer has both:

He has compared them and believes them to be the same work (see User talk:Dirk P Broer#The Mutant Weapon). As associated publications have quite a few primary verifications, I've created this centralized discussion to determine if there is agreement on that, and if so, whether both should be listed a novel or novella and then varianted. I will point the primary verfiers to this discussion. Thanks. -- JLaTondre (talk) 23:29, 3 August 2015 (UTC)

Several secondary sources give them as the same work. I would suggest making The Mutant Weapon into SHORTFICTION with novella length, and make it into the parent record. (Even though Med Service was published first, the second title appears to be the canonical one.) The two translated publications and one standalone reprint would have to be changed to CHAPBOOKs, with a SHORTFICTION content. The series numbering may have to also be adjusted or removed entirely. (BTW, SFE types The Mutant Weapon as a chapbook.) Mhhutchins 23:42, 3 August 2015 (UTC)
No objection from this primary verifier. Ahasuerus 01:19, 4 August 2015 (UTC)
Sounds fine to me, proceed.Kraang 02:07, 4 August 2015 (UTC)
OK by me. --Chris J 02:26, 4 August 2015 (UTC)
Since most people would recognize the later title it would make sense to use that as the canonical title. Since they are "exactly the same" the only question is whether to use the date associated with the canonical title or the earlier magazine appearance. Either way is fine by me.--swfritter 14:20, 4 August 2015 (UTC)
The date of the canonical title is always the date of its first appearance, even if it were published under a different title initially. See Asimov's What Is This Thing Called Love?, Clarke's Breaking Strain, and Bishop's The Angst, I Kid You Not, of God. Mhhutchins 15:05, 4 August 2015 (UTC)
No problem here. --Willem 18:00, 4 August 2015 (UTC)
I concur.Don Erikson 19:21, 4 August 2015 (UTC)
As do I. --Ron ~ RtraceTalk 01:57, 6 August 2015 (UTC)
Changes have been made. Thanks you all. -- JLaTondre (talk) 22:08, 8 August 2015 (UTC)

Changes to the way we link to third party sites

Back when we added links to third party sites like WorldCat and GoodReads, relatively few places would let you link using ISBN-13s. This has been slowly changing and now most sites support ISBN-13 links (including 979 ISBNs) while a few no longer support ISNB-10 links.

Based on the above, I have changed our linking logic to use ISBN-13s when linking to Barnes & Noble, GoodReads, WorldCat, Google Books, Fishpond, COPAC, LibraryThing, Shelfari, Powells, TextBook.com, eCampus.com, and Books-A-Million. I have also updated the logic that lets us link to Booka-A-Million to reflect their new URLs.

Please note that OpenLibrary couldn't be changed because they require the use of ISBN-10s for pre-2008 books and ISBN-13s for post-2008 books, which will require an additional, more involved, software change. Also, FishPond links are currently broken due a recent change to their URLs. I need to investigate the rest of the sites that we link to and see what needs to be changed. Ahasuerus 04:59, 4 August 2015 (UTC)

The link to Deutsche Nationalbibliothek needs to be corrected too, though not regarding ISBNs but the domain itself: it's "portal.dnb.de" now, without the dash. Visiting "portal.d-nb.de" without parameters already results in an automatic redirect to the new domain, however it seems they haven't implemented a redirect (yet) if you provide parameters (like the publication record paged does). You'll get a "invalid certificate" browser message then, because the certificate is only valid for the newer "dnb.de". Jens Hitspacebar
Thanks, Jens, I'll include this fix in the next round of ISBN changes. Ahasuerus 19:02, 4 August 2015 (UTC)
Fixed. Also, links to a number of other sites have been adjusted to use ISBN-13. The most obvious exception is Amazon, which doesn't support direct links using ISBN-13, but I think I should be able to code a workaround. Also, Deutsche Nationalbibliothek displays additional (invalid) pubs when you use ISBN-13s, so we are forced to continue linking using ISBN-10s. In addition, our links to European Library and Bibliotheque nationale de France appear to be once again broken due to recent URL changes. Ahasuerus 23:55, 5 August 2015 (UTC)
Amazon links for 979 ISBN-13s have been fixed. European Library and Bibliotheque nationale de France are still outstanding. Ahasuerus 21:47, 7 August 2015 (UTC)
European Library has been fixed, although their software requires the search string to match what's in their composite catalog verbatim. Since some of their member libraries store ISBNs with dashes ("979-10-90648-38-8") and some store them without dashes ("9791090648388"), our search string ended up looking like "979-10-90648-38-8 or 9791090648388". A bit odd, but it seems to work.
Unfortunately, I have been unable to find a way to link to Bibliotheque nationale de France. Unless someone finds a working URL by the end of the next week, I will remove BnF from our table of supported sites. Ahasuerus 23:21, 7 August 2015 (UTC)
BnF catalog can be searched by ISBN via http://catalogue.bnf.fr/servlet/AccueilConnecte?recherche=equation&Equation=ibn+=+MAGICNUMBER Replace "MAGICNUMBER" by ISBN. e.g., http://catalogue.bnf.fr/servlet/AccueilConnecte?recherche=equation&Equation=ibn+=+2720100226 for ISBN 2-7201-0022-6 (Le Tarnier de Gor). Uzume 21:59, 8 August 2015 (UTC)
Beautiful! Many thanks! (Patch installed.) Ahasuerus 02:17, 9 August 2015 (UTC)
P.S. I forgot to mention that "European Library (simple)" and "European Library (complex)" have been merged. Ahasuerus 23:24, 7 August 2015 (UTC)

(unindent) Open Library has been fixed. As far as I can tell, all of our links to third party sites should be functional now as well as support 979 ISBN-13s. I have closed the bug report. Ahasuerus 00:00, 11 August 2015 (UTC)

I recently updated ISFDB:Book sources for wiki links like: ISBN 978-0-06-441016-8 and ISBN 0-06-441016-1. I thought I would ask for Amazon CN, ES, IT, IN and JP link additions within the ISFDB software. They are not all the same (I especially find differences in Amazon JP vs, US, UK, and CA but it might be because I am looking at such more). Uzume 09:59, 16 August 2015 (UTC)
Sure. FR 820 has been created. Ahasuerus 18:56, 16 August 2015 (UTC)
I believe the URL format for linking between Amazon's different sites is mostly the same (at least backwards compatible so far as new methods work on all of them). What I meant is that the results are not the same. Uzume 10:03, 22 August 2015 (UTC)
Also I thought I bring up a few other issues with Amazon links.
First there is the fact that linking to the product detail page cannot in general be derived from the ISBN (historically book ASINs have mostly been in alignment but with ISBN-10s but they are not guaranteed to be and in fact I run into some cases some cases where they are not even beyond 979 ISBN-13s). Please refer to FAQ: ISBN-13 for Amazon Associates (which is why the "product" link from the ISBN wiki links I updated do not in general work and when they do only when used with an ISBN-10 that is equal to the same books ASIN).
Second there is the issue of affiliate tagging. In general one just needs to add "tag=<tag>" to the HTTP GET query string (adding the appropriate ampersand delimiter as required). This works with both search links and detail product links.
Also the UK and US detailed product links we are using is based on older recommendations. Instead of:
  • http://www.amazon.co.uk/exec/obidos/ASIN/<ASIN>/isfdb-21
  • http://www.amazon.com/gp/product/<ASIN>?ie=UTF8&tag=isfdbinternes-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=<ASIN>
These can be simplified to just:
  • http://www.amazon.co.uk/dp/<ASIN>?tag=isfdb-21
  • http://www.amazon.com/dp/<ASIN>?tag=isfdbinternes-20
However it would be better to use the search links:
  • http://www.amazon.co.uk/s?search-alias=stripbooks&field-isbn=<ISBN>&tag=isfdb-21
  • http://www.amazon.com/s?search-alias=stripbooks&field-isbn=<ISBN>&tag=isfdbinternes-20
since they work with ISBNs instead of ASINs (unless you use their Product Advertising API to derive the ASIN from the ISBN programmatically, e.g., with server-side mashup or client-side JavaScript.). Uzume 09:59, 16 August 2015 (UTC)
Yes, it's a known trade-off. The only way to link directly to a book's "product details" page is by using its ASIN in the URL. If you use the book's ISBN, you can only link to an Amazon search page, which will let the user go to the "product details" page. For e-books and 979 ISBNs we have no choice: we have to use the second method because there is no way to derive the ASIN from the book's ISBN. For 978 paper books, the ASIN is almost always (99%+?) the same as the ASIN and that's what we use to link directly to the "product details" page.
There are a few things that we could do in this area:
  • Implement FR 235, "Add support for external identifiers", which will include ASINs. This will also make it easier to capture and massage e-books without ISBNs.
  • Add JavaScript code to the Publication page which will dynamically query Amazon to determine the ASIN based on an ISBN. Once the ASIN has been retrieved, we can replace the displayed Amazon link(s).
  • Link to the search page for all books. It will marginally increase accuracy, but will require the user to click twice to get to the "product details" page. Ahasuerus 19:40, 16 August 2015 (UTC)
Actually we could do any and all of the above. I believe the first (external identifiers) would require the most work. I would prefer we went with the last option (link to search) and either also implement the second one or eventually implement it later. That way we can always provide an accurate static link while (perhaps later) also provide a direct link to the product for JavaScript users (if the JavaScript can find a single ASIN via their Product Advertising API then it can replace the static search link for those users). Uzume 09:38, 22 August 2015 (UTC)
In addition I would like to request a user setting for such third party and external links so they do not always open in a different target (aka window/tab). I believe there maybe a FR for this (but I thought I would reiterate such anyway). Thank you. Uzume 09:59, 16 August 2015 (UTC)
Yes, that would be FR 373. Ahasuerus 18:53, 16 August 2015 (UTC)
BTW, would you happen to know how to link to Fishpond records by ISBN? The old algorithm no longer works... Ahasuerus 18:53, 16 August 2015 (UTC)
Yes, I just fixed our ISFDB:Book sources (I basically just stole the code from Wikipedia:Book sources). The solution is to add "advanced_search_result.php". Fishpond can be searched by ISBN via http://www.fishpond.com.au/advanced_search_result.php?keywords=MAGICNUMBER Replace "MAGICNUMBER" by ISBN. e.g., http://www.fishpond.com.au/advanced_search_result.php?keywords=9780064410168 for ISBN 978-0-06-441016-8 (The End) Uzume 09:51, 22 August 2015 (UTC)
Thanks for reminding me about Wikipedia:Book sources! The linking logic has been fixed. Ahasuerus 01:22, 26 August 2015 (UTC)

Micheal C. Planck vs. M. C. Planck

Would anyone happen to know if Micheal C. Planck and M. C. Planck are the same person? Ahasuerus 16:09, 4 August 2015 (UTC)

According to his agent, "M.C." is "Micheal C.". Chavey 02:59, 5 August 2015 (UTC)
Thanks! Ahasuerus 04:07, 5 August 2015 (UTC)
And his parents didn't know how to spell "Michael". Mhhutchins 03:01, 5 August 2015 (UTC)
Agreed--I have never seen that spelling before (one of my favorite is the Scandinavian Mikkel). Uzume 22:28, 8 August 2015 (UTC)

Clarkesworld ownership?

Since someone has taken it upon themselves to change the manner in which the issue is identified (Issue # plus month in the pub title instead of just month) I assumed they were taking responsibility for entering issues and I stopped entering them. But no issues have been entered since then. Help in the Missing or variant dates section clearly states that issue number should not be used unless absolutely necessary to identify a publication. A new de facto standard, used by myself and others, uses both date and issue number. Fine by me when it further aids in identifying an issue. I will be more than willing to keep entering Clarkesworld if A) there is a consensus as to how it should be entered and B) somebody modifies the existing pubs to be consistent. Better yet would be for somebody to actually acquire the issues and verify them.--swfritter 16:21, 4 August 2015 (UTC)

It's a well-established precedent that a magazine which prominently displays the issue number on its cover can be titled with that number. That doesn't preclude the addition of a date as well. What is the objection to having both? I would think more identifying data is better than less. Look at almost any cover of Clarkesworld and the issue number is given. I've not found any that give the publication date. There are currently five years of issues which haven't been primary verified, so who would anyone notify if they wanted to edit them? Mhhutchins 17:09, 4 August 2015 (UTC)
The issue was first noticed by a moderator at which time it should have become a community issue.--swfritter 13:32, 5 August 2015 (UTC)

Seiun Award

I can't see this in the list of awards, but it's on par with the Hugo or Nebula, for Japan. Can someone create it so I can add the information in? (link) Also, if the Nihon SF Taisho could be added, that would be great, too. Thanks! ···日本穣 · 投稿 · Talk to Nihonjoe 21:22, 5 August 2015 (UTC)

If you volunteer to enter the award data, I will be all too happy to add these two! :-) Ahasuerus 22:42, 5 August 2015 (UTC)
That would be an excellent award to add to our collection! Chavey 03:05, 6 August 2015 (UTC)
I did it with the Carnegie award, so I can do it for these two. ···日本穣 · 投稿 · Talk to Nihonjoe 15:56, 6 August 2015 (UTC)
Done and done! If you need additional categories for these awards, please post a request here. Ahasuerus 04:16, 7 August 2015 (UTC)
Will do. Thanks. ···日本穣 · 投稿 · Talk to Nihonjoe 04:34, 7 August 2015 (UTC)
I've started adding publications so I can add the award to them, but some of the submissions seem to be languishing in non-approved status. Can we bump them along? A couple got approved last night, but I have more waiting now. Thanks. ···日本穣 · 投稿 · Talk to Nihonjoe 02:11, 8 August 2015 (UTC)
Done. Also moved all transliterated titles from the Synopsis field to the Title Note field. Ahasuerus 02:36, 8 August 2015 (UTC)
Thanks! ···日本穣 · 投稿 · Talk to Nihonjoe 02:49, 8 August 2015 (UTC)
Indeed thanks--that was one of the ones I was asking for earlier: Talk:Awards#Japanese awards Uzume 21:45, 8 August 2015 (UTC)

Ken Bruen "Jack Taylor" series spec fic?

Does anybody know why this series[1] is in Locus[2] and is there any spec fic elements? Just watched the series on BBC a few weeks ago, no ghosts, just a hard drinking Irishman.Kraang 02:48, 6 August 2015 (UTC)

Seeing things n/a in Locus. Will delete both novels and leave his shortfiction.Kraang 02:52, 6 August 2015 (UTC)

Clone Publication changes

Clone Publication has been modified to be in line with Add Publication, i.e. editors will no longer be able to change Title/Author data. Ahasuerus 21:37, 8 August 2015 (UTC)

Is that a good thing? I often used Clone Publication to add titles to a series (because many characteristics are the same, e.g., publisher, cover artist, etc. but that requires a change in title and sometimes authorship). Uzume 09:16, 16 August 2015 (UTC)
Well, Clone Publication doesn't create a new title (unless you add a Contents title), it just adds a new publication to the currently selected title. Changing the pub's author(s) would create a title/publication mismatch which will then appear on one of the cleanup reports. Ahasuerus 15:34, 16 August 2015 (UTC)
I just tried to create an entry for Neverwhere, and add "Author's Preferred Edition" to the title. I can't do this via cloning, and my attempt to create a variant title was rejected. What's the correct method for creating a new pub with a different title?TAWeiss 13:08, 29 August 2015 (UTC)
It would be a two step process. First, clone the existing pub. Second, when that is approved, edit the publication to add the subtitle to the publication. This will create a new publication with the same title record, but have the subtitle on the publication record. -- JLaTondre (talk) 15:10, 29 August 2015 (UTC)
The addition of "Author's Preferred Edition" should be used in the title field of the publication record, not in the title field of the title record. This addendum to the title doesn't create a variant title. See how this publication record has a title which differs from its title record's title. This is done in thousands of publication records in which the db editor adds a subtitle or series title to the pub record, but the canonical title remains the same without the creation of a variant. So as JLaTondre suggests, you have to add the subtitle in a second submission to update the publication record. Mhhutchins 17:41, 29 August 2015 (UTC)
This makes sense. The help section for creating Variants could use some clarity though.TAWeiss 14:06, 31 August 2015 (UTC)

Reverse the Posting Order of the Boards and Talk Pages?

I'd like to suggest reversing the order in which posts appear on the boards and talk pages. Newest post first, rather than last. Changing the order would make it easier to find the most recent posts and alleviate the urgency to archive long pages.--Rkihara 16:03, 10 August 2015 (UTC)

I don't think there is a way to change MediaWiki behavior to support this functionality, e.g. the "+" sign at the top of Wiki pages will always create a new section at the bottom of the page. Also, it would make the ISFDB Wiki behave differently vis a vis other Wikis out there, adding another "barrier to entry" for new users. Ahasuerus 17:19, 10 August 2015 (UTC)
And archiving doesn't make the information gone. The top of each of the main discussion boards has a list of archives which can easily be searched. Having fewer entries on the active discussion page makes it easier to find things, too. ···日本穣 · 投稿 · Talk to Nihonjoe 04:44, 11 August 2015 (UTC)
MediaWiki was never designed to work efficiently as a forum. This has plagued Wikimedia projects for some time as they have sought better ways to achieve such (e.g., LiquidThreads and now Flow). Uzume 09:24, 22 August 2015 (UTC)

Title Merge changes

Please note that the Title Merge logic has been changed to remove merged Synopsis and Note records from the database. (They used to hang around and mess up cleanup reports.) If you see anything strange going on with title merges, please report your findings here. Ahasuerus 03:41, 17 August 2015 (UTC)

Followup to Better way to find varianted or similar cover art

Since the proposal of that feature I submitted 655 variants and merges for coverart, most of them based on this functionality. It's a very helpful tool. My instance is fine, but always waiting a week to see result is a bit disturbing, so I would appreciate implementation in main source.

Code and source as already described are here: User_talk:Stoecker#Own_ISFDB_instance point 2.

Code has been change a bit since initial release. —The preceding unsigned comment was added by Stoecker (talk • contribs) .

I agree with the consensus, i.e. that the functionality is desirable. I'll just need to tweak the user interface to address the usability concerns mentioned earlier. Ahasuerus 18:50, 21 August 2015 (UTC)
Which are? E.g. the idea to split it into 1000 piece pages makes the whole idea useless. --Stoecker 08:54, 22 August 2015 (UTC)
I am afraid I am under the weather at the moment and can't do it justice. I'll take a closer look when I get better. Ahasuerus 18:03, 23 August 2015 (UTC)

Multiple cover artists

While I understand the idea behind the current multiple-artists results in multiple covers behaviour I find it rather disturbing. When multiple cover artists are added, then it should behave like all the other fields and create ONE title with multiple artists. To support the books with multiple covers I'd suggest a checkbox beside the first artists which when selected creates multiple titles, i.e. do what's default right now.

I already found a lot of wrong multi-cover publications (nearly all which have more than one artist) and fixed some of them, but not all. This is simply a highly unexpected behaviour. --Stoecker 16:08, 23 August 2015 (UTC)

This issue was previously reported as Bug 156. I think the consensus is that it would be beneficial to change the default behavior to create a single COVERART record as you described.
However, before we can do that, we need to come up with a way to handle books with multiple covers, including multiple covers done by multiple artists. It would appear that the most straightforward solution would be to convert the current multiply occurring "Artist" field to a multiply occurring "Cover Art" group of fields. Each "Cover Art" occurrence would then support multiply occurring "Artist" fields. It would be similar to the way the Content section works: it supports multiple "Title" groups and each group supports multiple "Author" fields.
Would this approach work for everybody? Ahasuerus 23:52, 25 August 2015 (UTC)
Sounds good to me. Stonecreek 03:31, 26 August 2015 (UTC)

I do not understand the text above completely, so I describe my ideas:

  • My first idea was to present a single coverart enter box like now, but with changed semantics for multi authors as proposed (i.e. only one title). Additionally add "COVERART" to the normal contents section (like INTERRIORART). For initial creating enter first cover normally at top, second at bottom (or both at bottom). For any later edit remove the display of coverart at top (only in case more than 1 exists) and show each at bottom (maybe with a note at top). This is to prevent overlooking the fact that more than one art exists (by showing it in one place rather than first at top and second and more at bottom).
  • My second solution is as proposed the checkbox, which switches between single-title and multi-title, but leave the "we need to edit the title" workaround as it is now. That would leave the current rather complicated procedure, but does not make it default. Easier to implement, but still hard to understand.

--Stoecker 15:13, 28 August 2015 (UTC)

Followup to Translations not shown on author page when not logged in

I found a very minimal fix to this issue: http://isfdb.stoecker.eu/patches/06_showall_default.patch - Simply set the default settings for data showing to show all languages when no user settings are done. This does not change behaviour for registered users, does not require major rework and has the desired result. As default the ISFDB would show all contents it has instead of hiding all the non-English works. --Stoecker 18:23, 25 August 2015 (UTC)

I am sure you are aware of it, but just to make sure that everyone is on the same page, let me clarify that the current default behavior is to hide non-English translations rather than "all the non-English works". Ahasuerus 01:21, 31 August 2015 (UTC)

This would also mean the search engines will find the non-English titles better. --Stoecker 18:23, 25 August 2015 (UTC)

It will probably change which pages (i.e. Summary vs. Title) the search engines display, but I am not sure the impact will be significant. Ahasuerus 01:21, 31 August 2015 (UTC)

If users have really trouble with large pages, then they can register and reduce the displayed data easily.

So my request is simply to reverse the default to a version suitable for non-English users . --Stoecker 18:23, 25 August 2015 (UTC)

I am not opposed to this change, but let me take a step back and remind everyone why the current behavior was decided upon 4+ years ago. The main concern that we had at the time was that Summary pages of popular authors would become unmanageable for casual unregistered users if we were to display all translations by default. That was just a guess based on our estimates of how many translations were out there "in the wild". Now that we actually have a lot of translated titles in the database, we are in a much better position to decide whether this issue is as serious as we thought it would be. What say you, fellow editors? Ahasuerus 01:21, 31 August 2015 (UTC)
I believe the default displayed titles on an author's summary page should be a) titles in the author's working language and any variants of that title in the same language, and b) any English translations and variants. I'm always logged in, but I recall the last time I accidentally logged out that there is a big notice about being able to set the default for those who register. In any case, even if the user chooses not to register, he/she will be able to see all titles and their publications once they click on the canonical title. I object to displaying all titles for the same reason it was initially thought to be the way to go: page clutter (or data overload if we're being polite.) Mhhutchins 02:03, 31 August 2015 (UTC)
Then the main question is: Why bother adding any translations? They aren't visible! I can't link to ISFDB in any way, so that e.g. all the German stuff for Eric Frank Russell is visible. Without a login you don't see 95% of the foreign language stuff (but always English, as this is hard-coded as preferred). Why should somebody actually bother to create a login for a database which does not seem to have any useful data? --Stoecker 17:12, 1 September 2015 (UTC)
If you are not logged in, it says "Showing English translations only. Logged in users can choose which translations are shown." at the top of the Summary page. Ahasuerus 23:55, 1 September 2015 (UTC)
Which is less than useful for someone who is following a link from a blogpost in German or French, etc and who has no expectation of needing to read English and very likely cannot read the note as described. Kevin 02:35, 2 September 2015 (UTC)
I started in 2013 to supplement the Wikipedia entry I made - until now that is not possible, as simple the world does not see the data. And yes, you can find something when you already know it is there, but for me that's useless as usually you search to find something new. --Stoecker 17:12, 1 September 2015 (UTC)
Regarding the size argument: E.G. Isaac Asimov has 13.000 lines, and takes 12 seconds to load here (8 on my server) to fully display and has a size of 720kb. With a bit of tweaking the server code I'm pretty sure that this could go down to 5s (instead of output each line individually do a combined output which is a lot faster) and 500kb (and also use compression to reduce transmission time). Alone removing the obsolete "http://www.isfdb.org" from the text reduces size to 614KB. So instead of crippling the output optimize the backend. Without all variants (i.e. current default) it takes 9 seconds and 420kb. Alone a server update thus could cover the speed increase and a rather small improvement could reduce half of the additional size. --Stoecker 17:12, 1 September 2015 (UTC)
The tests that I ran last year suggested that the performance problem with extra-long Summary pages was primarily on the "retrieving data from the database" side rather than on the transmitting and displaying side. Of course, what you are suggesting would help, but we will also want to optimize query logic, especially the part where we retrieve co-author information. All perfectly doable.
However, first we need to decide whether changing the default behavior to display all translations would result in unmanageably long Summary pages. Here is how much longer the proposed Summary pages will be for a few popular authors:
  • Asimov: 60% increase in the number of lines displayed
  • Dick: 125%
  • Ellison: 20%
  • Heinlein: 100%
  • Herbert: 65%
  • Le Guin: 35%
  • MacCaffrey: 40%
  • Silverberg: 30%
  • Zelazny: 40%
20-125% doesn't seem too bad, although I expect that the gap between the two modes will grow as we add more translations. Ahasuerus 23:55, 1 September 2015 (UTC)
And a bit of Javascript (e.g. JQuery) could increase readability much more than any leaving out of non English languages can do. ISFDB's style is something out of the early 90's, there have been many improvements since then and half a megabyte for a data loaded page is nothing nowadays. But sadly there is no sense in doing any improvements, as they wont be accepted anyway. --Stoecker 17:12, 1 September 2015 (UTC)
I am curious about the JavaScript/JQuery changes to increase readability. What kind of changes do you have in mind? Ahasuerus 23:55, 1 September 2015 (UTC)
See e.g http://webcloud.se/jQuery-Collapse/ for an example of collapse blocks. Allows to easy hide parts of the page without actually omitting it. --Stoecker 14:10, 2 September 2015 (UTC)
Are you suggesting that we should collapse individual title types like NOVELs, COLLECTIONs, etc? Or are you thinking about collapsing all translations for a given title? Ahasuerus 05:42, 6 September 2015 (UTC)
Essentially such a collapse option should be added to any block like novels, series, individual series, ... which may contain more than a few items (i.e. anything with sub-points) Question is which of these are default open and which are default closed and how user settings affect this and whether the selections are remembered in cookies and ... But I don't suggest anything because the simple discussion whether or not the non-English titles should be shown or not now takes me nearly 2 years. I can't estimate what a discussion to change layout would cost. 20 years? --Stoecker 19:32, 12 September 2015 (UTC)
OK, thanks for the clarification. Ahasuerus 00:59, 13 September 2015 (UTC)
This is an English-language database that contains publication records for works regardless of the language they're published in. I don't know of any non-English database that does that. The titles that are visible are the titles that were created by the author. Perhaps there should be a note (in English) at the top of each page saying "Click on the author's original title to see translated titles and their publications." Your saying that "Without a login you don't see 95% of the foreign language stuff" is just nonsensical. It's like saying "There's nothing on my computer screen until I actually click on the link that carries me to what I want to see." Mhhutchins 18:24, 1 September 2015 (UTC)
I'd prefer to back away from the nonsensical label. Imagine a user who doesn't speak English, following a link to the database (Perhaps from a German Blog or a French review). If the foreign language translations don't show up (by default, or perhaps by a flag in a link (but that's a larger software fix)), then the database is not readable/legible. Imagine someone searching in Google for a title. It's very possible that the foreign language title that linked them to an Authors bibliography will not be visible on the page. To that frustrated user, the database appears opaque and even though they followed a link that had French or German titles in the page preview... the page they land on has none of that text or language. Kevin 02:59, 2 September 2015 (UTC)
Well, you need to know enough English to understand what "Summary Bibliography", "Used These Alternate Names", "also appeared as", "Variant Title", "Serialization", "Fiction Series", "Novels", "Collections", etc mean. If you can't decipher "Showing English translations only. Logged in users can choose which translations are shown", you'll probably find the site hard to navigate. Ahasuerus 04:03, 2 September 2015 (UTC)
[After edit conflict] Maybe I don't know how Google works, but why would it give you a link to a page which doesn't contain the text you're looking for? I've tried a dozen examples of searching for translated titles using Google, and was returned links that went directly to the title page that contained the translated titles. There were no links to the author's summary page which didn't contain the text of the translated title.
Also, even with a registered account, you don't see 99.99% of the database, until you click on the link that carries you to what you're looking for. I hope that explains why I think Stoecker's statement doesn't make sense. Mhhutchins 04:12, 2 September 2015 (UTC)
It makes sense. If you go to a summary page about an author and only see some few entries (the said 5% which are e.g. anthologies without English original or chapter books) then you simply go away again. I'm a German reader and get redirected to the authors summary page and see only English titles, then I simply go away again. I don't read the page first to check if there may be a note telling me that I need a login (which BTW took me at least a month to see it first time when I came back this year). And BTW the purely english user interface is another point for me, but I don't even talk about that, although it's fixable relatively easy - I did I18N for many software projects already. When I at least see the titles, the interface language can be overlooked. Even when you don't understand the English texts the whole DB would still be usable. Many people learned to cope with English interfaces. But it should be clear nowadays, that the first impression counts a lot and not only the possibilities behind. And for non-English readers the first impression of ISFDB is the worst they can get - nothing visible. --Stoecker 14:10, 2 September 2015 (UTC)
I agree. A new non-English first-time visitor who wants to see if the ISFDB is a good source of information is clearly mislead by what's visible on the author's summary page without being logged in. There's only the hint: "Showing English translations only. Logged in users can choose which translations are shown." It's misleading because reading that one could think "WHAT?! I must register just to see other languages?!" and would probably leave the page for good. There's no indication on the page that if you click on a title you'd see more languages without login. Hitspacebar 19:09, 2 September 2015 (UTC)
Hm, I have never thought of this possible misinterpretation. If we decide to stick with the current approach, we will at least want to change the wording. Ahasuerus 06:23, 6 September 2015 (UTC)
If it's a really a problem with performance and/or too much clutter if all translations are shown, then why not show a new, clearly visible and informative text block somewhere on top of an author's page about the availability of translations for this author. Like this:
"Works of this author have been translated into the following languages (click on a title to see all of its translations):
* German
* Chinese
* Klingon" Hitspacebar 19:09, 2 September 2015 (UTC)
Unfortunately, the way the Summary Bibliography page works, we don't know which (if any) languages the author's works have been translated into until the whole page has been displayed. Ahasuerus 06:23, 6 September 2015 (UTC)
BTW: why does the hint say "Showing English translations..."? On an English author's page when only English titles are displayed it's completely wrong, and on a German author's page is at least partly wrong because English and German are displayed. It should be phrased "Showing English titles..." for English authors and "Showing [INSERT AUTHOR'S WORKING LANGUAGE] titles and English translations..." for non-English authors. Jens Hitspacebar 19:09, 2 September 2015 (UTC)
Not having done any coding for quite a few years I'm not sure about this but is there any reason that you couldn't extract the language from the user agent string in the browser and just display a note in that language along with the appropriate translations for non-registered/non-logged-in users?SFJuggler 04:08, 20 September 2015 (UTC)
An interesting thought. It's probably possible, although the "Accept-Language" string can be fairly complex. For example, "Accept-Language: da, en-gb;q=0.8, en;q=0.7" means "I prefer Danish, but will accept British English and other types of English."
If we are going to display all translations by default, which appears to be the majority opinion, then we don't have to worry about this. However, it will be something to consider if we decide to tweak other types of display based on the user's list of preferred languages. Thanks! Ahasuerus 00:36, 23 September 2015 (UTC)

(outdent) If we're going to limit translations, then I believe we should be consistent regardless of the author's language. We should only show parent records and variants in the author's primary language. So if an English writing author, then only show English variants. If a German author, then only show German variants. Our non-English coverage has dramatically increased in the last couple of years. If we don't want to burden English author pages with translations, I don't see a need to burden a German author's page with English translations. Either way, as Stoecker and Jens point out, the wording shown to non-logged in users needs to be improved. -- JLaTondre (talk) 00:18, 3 September 2015 (UTC)

It's certainly an option, but before we start discussing it, would you be in favor of Dirk's proposed change to the default behavior of the Summary page? If we decide to implement it, then the other issues raised here will be moot.
I'd like to invite all other editors to share their thoughts since this change will affect everyone. Ahasuerus 06:23, 6 September 2015 (UTC)
I didn't really follow the technical arguments (twenty years passed since I've written code and managed SQL databases). My opinion is that, regardless of size problems, we should immediately (without login) present our riches (our strenghtening international coverage which is, IMHO, unique) to the casual user. It means to show all titles in all languages. If there are still performance issues, perhaps some categories (ESSAY, INTERIORART) should be collapsed (I suppose that means that the user has to click on it to get the full list). Hauck 07:40, 6 September 2015 (UTC)
That's my opinion, too. English language titles may be the vast majority of data in the ISFDB for a very long time, but the ISFDB is definitely evolving more and more into something I'd call an "International Speculative Fiction Database" - and that fact should be immediately and intuitively clear as much as possible when you visit the site. Jens Hitspacebar 10:41, 6 September 2015 (UTC)
This database contains records of speculative fiction publications regardless of the language, but that doesn't negate the fact that it is an English language database. As much as it may be difficult for people to distinguish the difference, it's a fact that's not going to go away soon. Mhhutchins|talk 16:33, 19 September 2015 (UTC)

Goes this like always - A lot of discussion, people agree with the idea and nothing happens? --Stoecker 09:33, 19 September 2015 (UTC)

And some people disagree. Yes, that's how it "goes this like always." Mhhutchins|talk 16:33, 19 September 2015 (UTC)
So far the majority of those who have commented in this section has been in favor of the proposed change. However, I am concerned that relatively few active editors have expressed their opinions. It's possible that many editors have no preference, but it's also possible that they haven't read/understood what is being proposed. I plan to leave notes on the Talk pages of some of the more active editors and ask them to share their thoughts. Ahasuerus 23:51, 19 September 2015 (UTC)
Messages left. Apologies if I overlooked anyone! (And please don't hesitate to jump in.) Ahasuerus 01:23, 20 September 2015 (UTC)
Thanks for the ping. Great discussion. I'd vote for changing the current default. Reasons:
- 'Login' state is required for editing and setting personal defaults, but I'm not convinced it should be required to 'reveal' data.
- We all agree the default language for metadata in this wiki will be English. But that doesn't preclude or even deter many non-US enthusiasts. So the arguments about being welcoming to, and/or aspiring to grow, the non-US user base are compelling. This is a worthy aspiration.
- If we're going to burden our hard working admins with a change, and if display time is a problem worth fixing, then I'd suggest they consider any reasonably easy changes to shorten the display for mobile browsers (such as only showing English titles.) That would probably impact more users, especially over time given current trends.
IMO. Thanks for reading. Markwood 02:24, 20 September 2015 (UTC)
My opinion is basically the same as Hauck's. I think the database should show all titles in all languages without login. The notice should be reversed to say that by registering you can limit the languages shown on summary pages. --Jorssi|talk 08:19, 20 September 2015 (UTC)
I also think all languages should be displayed in the Summary pages. As it has been said above, it is an asset that few (if any) other db possess, and should be made evident from the start, login or no login. Linguist 08:40, 20 September 2015 (UTC).
I also think all languages should be displayed in the Summary pages.--Dirk P Broer 10:52, 20 September 2015 (UTC)
I'm not so sure of it: we still have only a few additional languages with a substantial amount of works, but there will be a really big wave of wworks in languages with only few representatives so far coming in. Please consider, if there's the chance of manageabibilty for, say, fifty additional languages. If you say yes to that, I'm all for the proposed change. If not, it'd be better to stick to a rephrasing of the heading. Stonecreek 13:18, 20 September 2015 (UTC)
Because (I suspect like most editors) I'm pretty much always logged in, even when I'm not active for a few days, it's tricky to accurately see the database as irregular, non-logged in users see it, or know/remember what the options are and how they're arranged. So after reading this thread I’ve just spent 10 minutes seeing how others may see us. Thoughts:
1) The header “Showing English translations only” is not appropriate for titles that were originally written in English, and should certainly read “English titles”. Can two headers be created for either English and non-English authors (for whom it would still read “English translations”)? But whatever the text of the header, as it is currently displayed it’s easy to overlook, so I reckon it needs to be a little more prominent, maybe with a yellow boxed background? But that's a tweak, and I'd prefer to see a bigger move.
2) I think restricting the visibilty of translations should be opt-in, not opt-out. I don’t see any harm at all in displaying all translations to the non-logged in user, and as was indicated up-thread, it's a question of deciding what information is deemed worthy of being made instantly available, and what isn't. For example, a link to a 1926 issue of Amazing Stories gives the non-logged in user everything we have. If a link provided to another user indicates we have a record of, say, a rare Arabic translation of a Japanese spec-fic novel, and the non-logged in user then can’t see that title or read enough English to know what to do next, we’ve got about two useful seconds to hook the guy before he closes the tab. Because he must then go through the hassle of setting up a free account in a foreign language to see the goods we freely provide. That sign-up procedure is only useful to simplifying the page display, and given that the greater majority of ISFDB users are already English-speakers, creating an account just to display maybe a few dozen extra lines of translations in a still-as-yet-incomplete Arthur C. Clarke bibliography might seem a tad unnecessary: why aren’t we showing that stuff up front? It’s just as useful to a different subset of people as the bibliographic details of that 1926 issue of Amazing Stories is to a different subset, and yet one use of the ISFDB, for some mysterious reason, provides an extra hurdle for the user to jump. No doubt restricting translations this way serves a useful purpose, but only if it's what individual users want, and we already have that option for them in place if they want to use it. PeteYoung 23:57, 20 September 2015 (UTC)
Pete, I think you're misunderstanding what is visible to non-registered users. They have the ability to see everything in the database, as much as anyone who has created an account. Anyone who wants to see the contents of a 1926 issue of Amazing Stories would have to have enough knowledge of English to search for it. Anyone who wants to see the records of every translation of Stranger in a Strange Land would only have to go to Robert A. Heinlein's summary page and click on its title. They are no more or less "visible" than any other data in the database, regardless of whether a user has an account. For some odd reason, it appears that some responses to this issue is assuming that a person must sign up for an account in order to see all of the translated titles of a work. I don't know how they got that impression. Mhhutchins|talk 03:40, 21 September 2015 (UTC)

I agree with most of the comments immediately above that the default view for non-logged-in users should include all translations. Yes, that creates a lot of useless information and slows things down for most people who are regular users, but we/they can opt out. For the first time user, even those whose primary language is English, I feel it is important to show them the scope of the data base immediately. It would be a plus to make the existence of the opt-out stand out more clearly that the current opt-in does. Bob 01:03, 21 September 2015 (UTC)

Read all the comments and agree we should display all translations, I believe it will make the data base more welcoming to new foreign users and possible future editors and moderators. I've looked at both pages and don't find the extra titles a burden and if I did I can opt out of any language.Kraang 02:00, 21 September 2015 (UTC)

But any non-registered user wouldn't have that option. You're forcing them to sign up just so they don't have to wade through hundreds of lines of data that they are may not be interested in. Mhhutchins|talk 03:40, 21 September 2015 (UTC)
One of the proposed changes is to add a "Hide/Show Translations" toggle to the Summary page. It will only be displayed to unregistered users and eliminate the need to register in order to hide translations. Ahasuerus 01:27, 23 September 2015 (UTC)
And even if they were, it's just a click away. Why do so many of you think the current system is hiding data from non-registered users? It's only one click to see all translations of a work. That doesn't seem like much of a burden to me. Mhhutchins|talk 03:40, 21 September 2015 (UTC)
I think the idea behind the proposed approach is that it's better to display all available information and then let the user decide whether s/he wants to limit what is displayed. Ahasuerus 01:27, 23 September 2015 (UTC)
After logging out and in, and changing my language prefs to all languages and back again, I came to some conclusions. As a first-time English speaking visitor, I'd like to see the uncluttered English only lists, not only for a cleaner Summary Biography page, but for the uncluttered Series pages. But I might appreciate the option to turn on all languages in a note, possibly with a checkbox, without signing up. A simple on/off switch. I don't know if that's feasible, not being a programmer.
As a non-English speaker, I'd probably like the default to be all languages shown, but could live with a prominently shown checkbox giving me that option, without registering. So, if possible, that's what I would do: leave it as is on first arrival to the site, with a prominent note saying that you can click here to see all languages but that you can customize your languages by registering. Doug / Vornoff 07:31, 21 September 2015 (UTC)

I'm in favor of showing all languages for not-logged-in users and to have a button to "hide translations" or "display translations". It would simply update the style sheet and would not be retained from page to page unless you feel like saving that in a cookie. I looked at Isaac Asimov from from the (hopeful) perspective of someone not familiar with ISFDB and one thing I saw is that the lines that say "Variant Title: Una Serata Di Canto [Italian] (1983)" should be worded as "Italian translation: Una Serata Di Canto (1983)". This can be detected as they are VTs where the language changes. The <li> blocks for those those lines would have class="translation" allowing the style sheet to display:none them. --Marc Kupper|talk 08:39, 21 September 2015 (UTC)

This functionality (and a similar Feature Request for the Title page) was mentioned back when the first version of language support was added. Unfortunately, it was deemed unfeasible at the time since 99% of our translated titles had no language codes associated with them. Of course, much has changed in the last 3-4 years. Once we finish cleaning up Titles without a Language by Non-English Authors, it should be relatively safe to implement these changes. Ahasuerus 01:20, 23 September 2015 (UTC)

Ahasuerus, can you tell from the web server or other logs the percentage of human users that are not signed in? How many pages do they access before leaving? Can you do a breakdown for what countries (using their IP address) they come to ISFDB from? --Marc Kupper|talk 08:39, 21 September 2015 (UTC)

We should be able to get some of this information using third party log parsers. It's been on my list of things to do for a few years, but I haven't had the time to work on it. (The other day Fixer found another 12,000 ISBNs for me to process :-( ) If we have volunteers, I could make our recent browser logs available via FTP. Ahasuerus 00:51, 23 September 2015 (UTC)

Stoecker and/or Ahasuerus - I know that the preferences are stored under a user ID or user number and that when I'm logged out that the preferences come from user #0. For a while this bug, ISFDB:Community Portal/Archive/Archive30#Loss of the Amazon links, existed where people could edit the user #0 settings. How hard would it be to set up the preferences page to check and if someone is not logged in to generate a temporary user number on the fly and to store it in a cookie? --Marc Kupper|talk 08:39, 21 September 2015 (UTC)

I don't think we need to worry about creating temporary user numbers on the fly. If we add a "Show/hide translations" toggle to the Summary page, the setting will be saved in a cookie. Ahasuerus 01:05, 23 September 2015 (UTC)
I think that would be a great addition. Kevin 01:18, 23 September 2015 (UTC)
I agree with the thought that all languages should be shown by default. I have set my preferences this way, and I don't find it to be a burden. It's even interesting to see all the languages Asimov has been translated into! :-) I do, though, like Marc's thought of some quick-and-easy session cookie that could be used to control the preference for a non-logged-in user. Even if that preference were simply: Show All vs. Exclude Translations (i.e., you get everything or you get whatever is in the author's original language). I suppose there could be a third, Show Only English, since English is the database's base as Michael says. But it doesn't need to be complicated -- for more precise language filtering, you have to log in; seems reasonable. --MartyD 11:38, 21 September 2015 (UTC)
I think it would be better to show only English, but have a link at the top of the list of works that toggles on other translations:

Showing the following translations: English (Show All, <Change Preferences | Login | Create Account>)

Then have "Show All" be a link which toggles on the display for all languages for that session, and then have a link to the My Languages page if they are logged in, and a link to Login or Create an Account if they are not logged in. This would give people the option, but not show all the other languages initially. ···日本穣 · 投稿 · Talk to Nihonjoe 04:21, 22 September 2015 (UTC)

(unindent) Here is the tally so far. 13 votes in favor of displaying all translations to unregistered users, 2 against, 2 on the fence. There is an additional proposal, which addresses some of the concerns that have been raised: add a "Show/Hide Translations" toggle to the Summary page. The toggle will only appear if the user is not registered (registered users can specify exactly what they want to see under User Preferences.) Ahasuerus 01:35, 23 September 2015 (UTC)

Could the toggle appear if selected in a user preference? Kevin 02:17, 23 September 2015 (UTC)
My current thinking is that the toggle will only appear for unregistered users. Ahasuerus 03:02, 23 September 2015 (UTC)
Also, could will we then get rid of the "You are not logged in. If you create a free account and sign in, you will be able to customize what is displayed." and similar messages, as well as the "Showing all translations (can be changed via My Languages under My Preferences)" on every page. Kevin 02:17, 23 September 2015 (UTC)
We can certainly change the text as part of (or shortly after) this round of changes. BTW, "Showing all translations (...)" is only supposed to be displayed if the current user hasn't set up his or her language preferences. Ahasuerus 03:02, 23 September 2015 (UTC)
Mine shows that constantly. If I change it from 'everything' to English only, I get "Showing the following translations: English (can be changed via My Languages under My Preferences)" Kevin 03:12, 23 September 2015 (UTC)
Oops! Sorry, I forgot that there is a User Preference for it, "Do not display translation warnings on Author Bibliography pages". Perhaps it will be no longer necessary after the next round of changes. Ahasuerus 03:21, 23 September 2015 (UTC)
Aha! Thank you! Kevin 12:37, 23 September 2015 (UTC)

(unindent) OK, FR 830 has been created. Ahasuerus 15:31, 24 September 2015 (UTC)

Trans. of instead of variant of

On this page about art book Solar Wind, several content lines show "trans. of" instead of "variant of". This appears to be caused by the coverart having a non-empty language property. It is not possible for me to empty this language property. A general solution, nullify the language of all coverart, might be best. I also request to make it impossible to create new such cases, or add this to periodic clean-up scripts. Thank you. Horzel 09:54, 27 August 2015 (UTC)

There were talks of such a move (nullify the language for artwork), but IIRC, nothing was decided. FYI, I'm strongly opposed to it. IMHO a cover or piece of art has a language and the fact that such or such artwork was used for a book of a given nationality is a valuable piece of data that must be immediately accessible. Hauck 11:25, 27 August 2015 (UTC)
I respectfully disagree. A Title of Type: COVERART can be part of several Publications, each of which may have a different language (e.g. here. Which language should then be the language of the coverart? The lettering on the cover should not be considered to be part of the coverart. Horzel 12:54, 27 August 2015 (UTC)
Right. We go for the art (that is the part we are interested in, I think). We overcame that the only role of any language is played in art of the types map or cartoons with captions that are actually translated. As I understand it that is the problem we still face: to identify those pieces that fall into one of these categories. Christian Stonecreek 13:39, 27 August 2015 (UTC)
OK, let's talk about art. What interests me (among other things) is for example in this case (note that we're at artwork level) to see in one glance that this artwork was used on an english, german, dutch and french book. Supposing that I'm completely tongue-deaf, I will need about eight clicks to obtain the same information without a language assigned to the artwork (go to each publication THEN to each title).Hauck 13:53, 27 August 2015 (UTC)
Art has no language, and as Christian says, the ISFDB record represents the art itself. The title fields of the title records only record the titles of the publications on which they were published. (That's why we variant it if the title changes when the artwork is used on another publication.) It's very easy to follow the link back to the original publication record to determine the language of the work. Except for maps, all interiorart and cover art should not be assigned language, in my opinion. Nullifying that field for all such records would solve the problem you're talking about. Mhhutchins 17:27, 27 August 2015 (UTC)
Note that I didn't say that it was not easy (to obtain the diverse languages involved), I said that it was time-consuming. I won't comment the "Art has no language" part, it's just a generality that some studies dispust (just think about the diverse "directions" (left to right, right to left, top to bottom) of written languages and their impact). Hauck 16:51, 28 August 2015 (UTC)

Changing Elizabeth Bears New Amsterdam from 'Novel' to 'Collection'

I'd like to propose changing Elizabeth Bear's New Amsterdam from a 'Novel' to a 'Collection', and there are four PVs currently on two of the Novel publications. This is a borderline case, however due to one portion being nominated for an award, I think the scales are tipped towards 'Collection'. I understand that when it first came out it was a bit of an odd duckling, however it seems the consensus has leaned towards a collection.

  • Supporting
    • Les Innocents/Lumiere was Nominated for a Sidewise Short Form award in 2007.
    • Locus scored New Amsterdam as 6th in it's "Best New Collection" awards in 2008.
    • The Verified hardcover notes state (emphasis mine) "No Table of Contents. The book is divided into named parts rather than chapters. These are: Lucifugous (p. 7); Wax (p. 63); Wane (p. 91); Limerent (p. 113); Chatoyant (p. 151); Lumière (p. 203). Each part is a self-contained story; all part of a larger story."
    • SFE refers to it "...like the New Amsterdam sequence beginning with New Amsterdam (coll of linked stories 2007),..." and again as "New Amsterdam (Burton, Michigan: Subterranean Press, 2007) [coll of linked stories: New Amsterdam: hb/Patrick Arrasmith]"
    • According to a note in the New Amsterdam Series record, The Introduction to Garret Investigates (published several years later) in describing a timeline of events, refers to various titles as having been "~collected in New Amsterdam, Subterranean Press, 2007" and other titles as "*collected in Garrett Investigates, Subterranean Press, 2012". This can be confirmed via the Amazon Look Inside view of that title.
  • Opposing
    • Gaylactic Spectrum Award short listed it for Best Novel in 2008
    • The Verified Hardcover notes state "Copyright page states "Portions of New Amsterdam appeared in somewhat different form in Interzone and Subterranean"" which is a common indicator of a true fix-up novel that weaves previous short stories together (in stead of simply stapling them together as in a collection).

I'm dropping notes on all the PV pages and inviting them here to comment, and inviting comments from anyone else. Thanks Kevin 16:18, 28 August 2015 (UTC)

I would stick to the established usage as per this precedent keeping the title as a NOVEL mainly because most of the material didn't see any individual publication (a COLLECTION will create some "artificial" short stories). The fact that some texts were modified from original publication is also indeed the mark of a fix-up (NOVEL). Hauck 16:42, 28 August 2015 (UTC)
I have no dog in the fight, but I'd advise keeping it as a novel with notes in the title record to explain how the work is structured. The author herself calls it a novel and that's good enough for me. Mhhutchins 17:20, 28 August 2015 (UTC)
Both comments above reinforce my belief this is indeed a fix-up novel rather than a collection. Bob 21:58, 28 August 2015 (UTC)
Two out of three active Verifiers speak. Sounds decided to me. A Novel it stays. Thanks! Kevin 01:18, 29 August 2015 (UTC)

"Mutant", by "Lewis Padgett"

We have the collection Mutant listed as by "Lewis Padgett", being used as a pseudonym by Henry Kuttner. This collection consists of 5 stories, each of which we have credited to "Lewis Padgett" as a pseudonym for the team of Henry Kuttner and C.L. Moore. It seems to me that that means something is attributed incorrectly. Either those stories need to be credited to Kuttner alone, or else the book should be credited to them both. I know we've had discussions about Padgett/Kuttner/Moore, but Google search couldn't find any discussion of this particular book. Does anyone know why this collection *isn't* attributed to Kuttner & Moore? Chavey 06:52, 2 September 2015 (UTC)

There's really no need for discussion. If we've determined that all of its contents were pseudonymously written by Kuttner and Moote, then the title record should be varianted to both as well. I'll do it. Thanks for finding this. Mhhutchins 01:11, 3 September 2015 (UTC)
Thanks. I've been mistaken in my handling of Lewis Padgett works before, so I didn't want to change this on my own. Chavey 04:21, 3 September 2015 (UTC)

How to link "Atelier Heinrichs" and "Atelier Heinrichs & Bachmann"

In 1967 the name of the Atelier changed to include Bachmann. Maybe in the 80ies it changed back or that single entry is an error. Anyway I'd like to know if there is a chance to somehow link or join these entries (http://www.isfdb.org/cgi-bin/ea.cgi?158811, http://www.isfdb.org/cgi-bin/ea.cgi?184937)? --Stoecker 22:58, 4 September 2015 (UTC)

You'd first determine which one is the canonical form of the name. Then make the other one into a pseudonym. Then variant the pseudonymously credited titles to the canonical name. All of the titles will then appear on a single page, Mhhutchins 23:01, 4 September 2015 (UTC)
That does not apply here. I assume that's really an Atelier, so multiple people may have been working on the pictures: So it's not pseudonymable or variantable in the way like it is for most authors.

Timeline:

--Stoecker 23:17, 4 September 2015 (UTC)

Then I'm not sure exactly what you're asking. I misunderstood your original post to indicate that it was the same entity, only that it had "changed" its name. If not, then there's no way to link these credits. They will have to remain separate, as well they should be. Mhhutchins 23:38, 4 September 2015 (UTC)
I assume it's the normal life cycle of such an Atelier, that people join interest and later go different ways. But the allover fact is, that the major person here is Dieter Heinrichs. Currently these are three independent entries. But there are not. They are linked. As there is no note field like for titles I can't add a note. Creating a "Dieter Heinrichs" and linking all there is wrong, as these are group works and with changing participants. I search a way to make clear how these 3 entries (or maybe more when Atelier Bachman appears in more than a note) are linked which is reachable from the title pages, so that it is visible to someone viewing the entries. --Stoecker 09:35, 5 September 2015 (UTC)
If there is a single company and it is the same company throughout name changes, then a pseudonym can be used to link them. The canonical name would be canonical name of the company, not a person. See Blacksheep for an example. As that seems not to be the case here, you can add notes using the "Biography" pages. Go to the applicable author entries and click the red link next to the "Biography" line. That will take you to the linked wiki page where you can add information. You can link between the wiki pages. In the future, I believe the intent is to migrate the Biography & Bibliographic Comments to the database and stop using the wiki, but for now, that is where author notes go. -- JLaTondre (talk) 11:46, 5 September 2015 (UTC)

Seanan McGuire's "Reflections"

Here is an interesting scenario that I don't recall seeing before. Seanan McGuire is currently in the middle of publishing Reflections, volume 2 in her Indexing series, as a "Kindle serial". To quote Amazon:

  • This book is a Kindle Serial and continues the twelve-episode story in Indexing (Book 1). Kindle Serials are stories published in episodes, with future episodes delivered at no additional cost. This serial currently contains two episodes out of an estimated twelve total episodes, and new episodes will be delivered every two weeks. ... An additional episode will be delivered every two weeks until the book is complete. New episodes will be added to the same book on your Kindle, keeping your place and retaining your notes and highlights. You'll be notified via email when a new episode has been delivered.

For now, I have entered it as a NOVEL, but I wonder if there is a better way to handle the situation. A 12-part SERIAL seems excessive, but I am not sure what else we can do. Ahasuerus 02:55, 6 September 2015 (UTC)

Unlike a normal serialization (Where someone might own only one portion of the full title...) in this case, the single purchase results in ownership of all portions of the title. I would think Novel at first, with chapter titles (if they have them) in notes. That however could get changed to Collection of titles at a later date if portions are broken out for individual publication. Kevin 15:00, 6 September 2015 (UTC)
I agree with Kevin. If a reader is not allowed to purchase the episodes individually, then it should be entered as NOVEL with notes. Let's say in the case of another work that a reader chooses to read only a few chapters each week, even though they purchased the entire work. That wouldn't make the work into a SERIAL. Mhhutchins 03:50, 7 September 2015 (UTC)
Sounds good. Thanks for your thoughts! Ahasuerus 17:45, 8 September 2015 (UTC)

Smith's Monthly

Dean Wesley Smith is one of the most prolific genre writers out there. Our bibliography barely scratches the surface because we have none of his pseudonymously published non-SF works -- see this post for some (not many) details.

A couple of years ago he started an unusual project, Smith's Monthly. It's a monthly magazine consisting exclusively of his stories, serialized novels, poems, articles and so on. At this time we have only 4 out of 21 issues entered, some with partial contents. I'd like to call for volunteers to enter the rest of the issues/stories. Ahasuerus 18:05, 8 September 2015 (UTC)

I'm on to it. --Chris J 00:31, 9 September 2015 (UTC)
Thanks! Ahasuerus 01:35, 9 September 2015 (UTC)

Brief ISFDB outage

There will be a brief outage between 11:30pm and 11:35pm server time. Ahasuerus 04:24, 9 September 2015 (UTC)

Everything should be back up. Ahasuerus 04:33, 9 September 2015 (UTC)

New option - Check Duplicates for a single title record

A single-title version of "Check Duplicates" is now accessible from the Title page. In addition, moderators can access "Check Duplicates" from the post-approval page for Edit Title submissions. Ahasuerus 04:43, 9 September 2015 (UTC)

The post-approval page for Unmerge Title has been changed to allow checking for duplicates of all newly created titles. Ahasuerus 22:56, 9 September 2015 (UTC)

Linking to the British Library catalogue records (BLIC)

The permalink to records on the British Library website has been changed. Where previously the link was:

http://catalogue.bl.uk/primo_library/libweb/action/search.do?&vl(freeText0)=1234567890&fn=search

It should now be entered as :

http://explore.bl.uk/primo_library/libweb/action/search.do?&vl(freeText0)=1234567890&fn=search

The only difference is the change from "catalogue" to "explore". Is there a way for the system to update the ISFDB records without manually editing each one? If not, it shouldn't be too hard since there are currently less than 100 records which use this link to the BLIC. Mhhutchins|talk 20:43, 10 September 2015 (UTC)

I would suggest that we handle this change manually. Once we add support for "third party identifiers", subsequent changes to 3rd party URLs will be easy to handle programmatically. Ahasuerus 04:40, 11 September 2015 (UTC)

Unfortunately, there are still more than 1200 records which were linked before it was discovered (more than three years ago) that the links were temporary and expired when the user's session was terminated. Mhhutchins|talk 20:43, 10 September 2015 (UTC)

Pierre Barbet's "A Problem in Bionics"

Would anyone happen to know the parent title of Pierre Barbet's "A Problem in Bionics"? We are also missing the parents of half a dozen other translations in The Best from the Rest of the World: European Science Fiction in case anyone has additional insight. Ahasuerus 22:59, 10 September 2015 (UTC)

It's _les papillons sont au parfum_ first published in 1974. Hauck 07:07, 11 September 2015 (UTC)
Thanks! Ahasuerus 15:30, 11 September 2015 (UTC)

Brief outage - 2015-09-12

I will be taking the application down at 10pm server (US Central) time. Everything should be back up within 5 minutes. Ahasuerus 02:26, 13 September 2015 (UTC)

The outage will take somewhat longer than expected due to minor technical problems. Ahasuerus 03:05, 13 September 2015 (UTC)
Everything should be up and running now. Ahasuerus 03:10, 13 September 2015 (UTC)

Cleanup reports revamped

Non-moderators have been given access to 8 cleanup reports. You will see a new option, "Cleanup Reports", in the navigation bar on the left. Please feel free to create submissions to add/edit whatever data may be missing/invalid.

If you are a moderator, please note the "Cleanup Reports" option has moved within the navigation bar. Also, the cleanup menu has been modified to display asterisks next to the reports that everyone has access to. Finally, please note that the "Ignore" columns are only visible if you are signed in as a moderator. Ahasuerus 03:34, 13 September 2015 (UTC)

Nice! :) But I don't get what the "Container Titles in Publications with no Contents" report is about. Jens Hitspacebar 10:05, 13 September 2015 (UTC)
The original idea was to identify all anthologies/collections without Contents items. Unfortunately, we have a lot of them and it's not always easy to find the stories that they contain. I ended up limiting the report to ANTHOLOGY/COLLECTION titles with two types of publications (editions, if you will) associated with them: editions with contents and editions without contents. The hope is that in most cases (emphasis on "most") we can simply import the contents of the former into the latter. Ahasuerus 15:52, 13 September 2015 (UTC)
Ok. That's what I assumend, but the example below was confusing me. Hitspacebar 16:42, 13 September 2015 (UTC)
For example, the title of German version of Ray Bradbury's "Illustrated Man" is listed there. However, all publications of this title have fiction contents and none is "without fiction". And why is the "Space Opera" publication listed in the report as "[EMPTY]"? It's not empty, it contains two collections and a novel. Jens Hitspacebar 10:05, 13 September 2015 (UTC)
An omnibus pub which includes a collection should also include that collection's Content items. Otherwise the omnibus pub will not appear on the contained Title record's Title page. Ahasuerus 15:52, 13 September 2015 (UTC)
I see, thanks! In hindsight and thinking about the data model again it's obvious now, but I still sometimes get the differences between the title type and the publication type mixed up. Hitspacebar 16:42, 13 September 2015 (UTC)
BTW: I already looked at the "cleanup_report.py" and "nightly_update.py" files to find out myself what the reports does, but when I saw how many magic numbers instead of descriptive names are used there I soon gave up. You should really stop using them, it's less error-prone and more attractive for other developers. And it's really no fun trying to find out the meanings of all the magic numbers if you're trying to understand the code. Jens Hitspacebar 10:05, 13 September 2015 (UTC)
Are you referring to report numbers (1-93 and 9999)? They are based on a translation table in reportsDict, which can be found in edit/isfdblib.py. Ahasuerus 16:04, 13 September 2015 (UTC)
Yes. I saw already that you're using the reports numbers in order to be able to call "functionNUMBER()" dynamically in cleanup_report.py. But I also meant conditions like and v.reference_id IN (1,12,15,16,17,18). I know that's easy to read once you've made yourself familiar with the code but it's cumbersome to decipher if you're not. Hitspacebar 16:42, 13 September 2015 (UTC)
Oh, that. Yes, I need to do something about them. Thanks for the reminder! Ahasuerus 16:57, 13 September 2015 (UTC)

Recent Changes wiki page

Has anyone else been experiencing strange behavior from the Recent Changes page for the past few days? Any time I toggle the arrow to display multiple changes on a single page it affects the display of other pages on the list: removing the links to contributors talk and user pages, sometimes the "contribs" and "block" links associated with the user. I can work around it be untoggling the display arrows, but this is quite disconcerting. Mhhutchins|talk 21:03, 15 September 2015 (UTC)

I seem to be unable to recreate the problem. Have you tried using a different browser? Hitting Control-F5? Purging the browser cache? Ahasuerus 22:38, 15 September 2015 (UTC)
I can deal with it if it means having to change my preferred browser. I'm always clearing my cache so I don't think that will make a difference. I'll try it though. Mhhutchins|talk 23:08, 15 September 2015 (UTC)

Here's what it looks like.

Recent_changes.jpg

(after edit conflict)

If using a different browser resolves the display issue, it may help diagnose the underlying problem.

At one point Al was going to look into installing a newer version of the Wiki software, which could theoretically introduce new, unexpected bugs. However, I see no indication that there have been any Wiki changes in the last year, so I suspect that it's one of the following three things:

  • A. A recently introduced browser bug
  • B. A corruption within your browser's database (browsers have built-in mini-databases these days!)
  • C. An unusual character on the Recent Changes page which confuses your browser

If it's C, then tweaking how far back the Recent Changes page should go may help identify the offender. Ahasuerus 23:25, 15 September 2015 (UTC)

I tried it on Internet Explorer (yuck) and the display bug isn't there. If it means changing to IE, I can put up with a lot worse than this minor quirk. Mhhutchins|talk 23:40, 15 September 2015 (UTC)

Web pages - bug fix

Earlier this year I discovered that we had an ancient (ca. 2006) bug that had to do with the way the software filed 3rd party URLs and authors' e-mail addresses. Non-English characters like "ö" would cause the filing process to skip the affected URL as well as any URLs that followed it. All title types that support 3rd party URLs (authors, titles, publishers, etc) were affected.

Author filing was fixed back in April. All other record types were fixed earlier tonight. If you run into anything unusual, please post your findings here. Ahasuerus 01:23, 16 September 2015 (UTC)

Consolidating Publication Series data

I am sure many of you will recall that the ISFDB software was originally designed to support regular ("title") series, but there was no support for publication series in the 2004-2006 implementation. For a while we had no choice but to use the ISFDB Wiki to record publication series data. Then, in 2010, we enhanced the software to support publication series natively and the majority of pub series-specific Wiki pages were migrated to the database. Nonetheless, the Wiki still has 21 pub series (or related) pages.

Ideally, I'd like to see all of this data migrated to the database proper. In some cases, e.g. Paizo Publishing's Planet Stories Series, it should be a simple task -- confirm that what we have in the database matches what is in the Wiki, then delete the Wiki page. In certain cases, e.g. Ballantine Adult Fantasy Series, the Wiki page contains additional information which will need to be migrated to the Notes field, but it should be a reasonably straightforward process.

On the other hand, we also have a number of more elaborate Wiki pages like Easton's Masterpieces of Science Fiction. They contain additional information, often in some kind of tabular or pictorial format (see Series:Winston Science Fiction), which would be unwieldy to reproduce as ISFDB-native Notes. These more complex Wiki pages are usually linked to by their respective ISFDB pages, which seems to work reasonably well. There may be a way to modify the software to handle this information better, but that's fodder for another, more far-reaching, discussion in the context of handling author Bio/Biblio notes. For now I'd just like to make sure that there are no objections to moving all simple cases from the Wiki to the database. Ahasuerus 02:39, 16 September 2015 (UTC)

No objection from me. Stonecreek 04:19, 16 September 2015 (UTC)
Concur. So long as we keep the complex stuff like the Winston page. Yes It's largely duplicate 'data', but it's a better communication of that data. Kevin 12:39, 17 September 2015 (UTC)
Would you say that something like Avon SF Rediscovery can be deleted? The same cover scans are available on the Pub Series page via "show covers". Ahasuerus 21:36, 17 September 2015 (UTC)
I believe this was one of Michael's projects. No objections from me. --Willem 08:04, 18 September 2015 (UTC)
I don't have a significant amount of concern, but I want to point out that it's an inelegant/unequal substitute. The "Show Covers" functionality includes all later printings of the same editions. The wiki page however presents the series and is able to intelligently ignore later printings. Kevin 16:15, 18 September 2015 (UTC)
I copied all of the data from Easton's "Masterpieces of Science Fiction" wiki page into the Publication Series. I don't think it's unwieldy, although it does mean that the "regular" data for that series is 5 screen pages down. Chavey 17:31, 18 September 2015 (UTC)
That's a very good example of another issue that I was going to raise as we get ready to migrate Author Bio/Biblio notes to the database. I will start a new discussion shortly. Ahasuerus 18:06, 18 September 2015 (UTC)

Web pages - bug fix #2

Another bug affecting multiply occurring fields (Web pages, e-mail addresses and transliterated legal names) has been identified and fixed. The issue was very obscure and unlikely to affect regular submissions, so I am posting this notice just to be on the safe side. If you see anything unusual post-fix, please post your findings here. Ahasuerus 01:43, 17 September 2015 (UTC)

Author searches and transliterated legal names

Regular Search and Advanced Search have been enhanced to display authors' transliterated legal names as mouse-over bubbles. A search on "ovsky" should provide a representative sample. Boris Pokrovsky and Osip Senkovsky can serve as examples of multiple transliterated legal names.

If everything looks OK, we can use this approach when adding transliterated versions of other fields: pub series, publishers, pubs, titles and ultimately authors. Ahasuerus 03:11, 18 September 2015 (UTC)

Performance problems -- 2015-09-18

I am aware of the sporadic performance problems that we have been experiencing for the last hour. It would appear that our (virtual) server is unstable, something that we have no control over. It's getting worse, so it will probably crash and be automatically rebooted shortly. Ahasuerus 18:31, 18 September 2015 (UTC)

Primary Verification against a publicly available online Scan

I'm torn about the use of Primary Verification slots, for rare items that are chiefly available through public domain and publicly available scans of the original work. This applies mainly to works pre-1923, however there are many items after that date that have also fallen out of (U.S.) copyright, and many more will begin to enter the (U.S.) public domain in 2019. Kevin 16:49, 20 September 2015 (UTC)

In some cases, I have marked PV when I enter a work from an online scan. This documents that the information has been taken from a Primary source. However it incorrectly implies that I should be consulted if an update needs to be considered for that record. Since the primary source documents are freely available, any editor is capable using the online scan to confirm an issue of fact. (e.g. Interior artwork credits). Kevin 16:49, 20 September 2015 (UTC)
I'd like to propose a new PV type verification. This PV is only against an 'image true' scan of the publication being verified. The online scan must be freely available to the general public of a country or a copyright domain (doesn't need to be worldwide). Kevin 16:49, 20 September 2015 (UTC)
I believe that the Transient PV is insufficient on its own to document this type of verification, because transient implies that the publication will not be available to the verifier in the future. Items that have entered the public domain, and that have existing online scans, have little chance of becoming 'unavailable' without wholesale disruption of the internet. Kevin 16:49, 20 September 2015 (UTC)
I propose 'Online Scan Verification' as a potential name, but I honestly would be happy with any name. Kevin 16:49, 20 September 2015 (UTC)
However, I could be imagining a need that only I perceive. I'm open to that conclusion as well. I'm an itinerant Mod/Editor. My concerns may be far out in left field compared to the majority/consensus. I tried to break this up into some obvious discussion threads. Feel free to comment in line above as appropriate, or below here in general. Thanks Kevin 16:49, 20 September 2015 (UTC)
I find this notion a bit too sophisticated and I'm not in favor of multiplying the types of primary verification (weve already got "transient"). Also the PVing process is, in my mind, linked to a "physical" examination of the book.Hauck 17:05, 20 September 2015 (UTC)
I agree with Hervé. We don't need another verification slot. In fact, I don't think PV should be used for this source either. It is quite easy to note that "The data for this record is from a scan and not a physical examination of the publication." It's the very definition of "secondary source." I discovered that another editor was using scans as a source and giving a PV of the record without noting that. This isn't what primary verification means, at least according to the ISFDB definition. Mhhutchins|talk 18:22, 20 September 2015 (UTC)
I too have added primary verifications based on scans of the original work. When I began doing so, I do recall discussing it with someone (Kevin?) who agreed it was proper to do so. I also recall being told, some years ago in one of the community forums, that a primary verfication is appropriate when working from a photocopy of the publication. I do see the utility in Kevin's suggestion, though I would suggest the name "facsimile" and also include photocopies and facsimile reprints that purport to reproduce the original work exactly (e.g. the Girasol Collectible reprints of magazines). In my opinion, a verification with such sources indicate a more accurate record than any of the secondary reference works. Having such an option as one of the standard sources makes more sense than Bleler1 which is primarily a reference of stories (i.e. titles) rather than publications. --Ron ~ RtraceTalk 20:08, 20 September 2015 (UTC)
I'm not saying there's no value in scans as a source of data. Of course, it's more valuable than a standard secondary source. I'm only using the ISFDB definition of what primary verification means. You click a button saying your source is the publication itself, or you note the source in the Note field. There's a pretty clear distinction here. A facsimile reprint in your hand is different from a scan on your computer screen from a website of a file which may disappear tomorrow. What's the big deal about not wanting to note that in the record? (That was the crux of my discussion with you about primary verifying based on a Google Books or Archive.org scan.) Mhhutchins|talk 21:30, 20 September 2015 (UTC)
Noting the source of the verification was not in question when we discussed it. Rather you had expressed the same concern, as above, about the transience of the data online. As a result of that conversation I began archiving my own copy of the scans locally, which is a practice I would encourage for anyone doing these sorts of verifications. I don't think anyone is suggesting that the source of the data not be noted. When I asked the question four years ago, I was told to use a primary verification for photocopies. I extrapolated for electronic scans. Indeed the original conversation appeared to be proceeding along those lines including the same suggestion that Kevin offered above of a dedicated verifcation type for facsimiles. I still think it is a good idea and would show at a glance whether a publication had been compared against a facsimile. --Ron ~ RtraceTalk 22:59, 20 September 2015 (UTC)
I have 100 or so books in the range 1794-1923, and it is a little odd when I go to verify one of them and find out someone else has done a PV on a scan, and so I get the PV2 spot. But nevertheless, I still support the concept of doing that as a PV. I understand the possibility that the online pdf might go away, but I don't think that's any different than a PV that was done by an editor who is no longer with us (in one way or another). In general, I suspect these online copies from solid sources will stay around longer than the average editor. One problem is that these online scans occasionally are from rebound library books that are missing the original cover, in which case the scan is missing some important information that a "true" PV would have, and we can't get a cover picture that a visitor can use for verification purposes. But that doesn't strike me as much different than a PV done from a book that is missing its dust jacket. Or picturing only the dust jacket when 90% of available copies are missing the DJ, so you can't use our picture for verification purposes anyway. I agree that this "feels" like a secondary verification, but unless we actually add a new type of verification (which doesn't seem to be a popular option), that the right place to put this is as a Primary, with a note as to where it came from. Chavey 14:28, 22 September 2015 (UTC)
If anyone feels strongly enough that scans should be acknowledged as a source for primary verification, then a discussion should be started on the Rules & Standards page to change the ISFDB definition. Mhhutchins|talk 15:09, 22 September 2015 (UTC)
I did, and I do. However I started the discussion here to create a 'new' type of Verification that is almost equal to PV, that will get it's own definition, either as an addendum to the Primary Verification definition (as the Transient is defined now) or as an independent definition. I think jumping to "Shall we change the definition of PV?" to be part of a secondary question. The primary question is related to accuracy/reliability of an online scan compared to all other secondary sources. Doesn't it rise above all other secondary sources by it's very nature? If it does rise to the highest possible level of secondary source (barring possession of a Star Trek Holo-Deck), doesn't it deserve that recognition? (The question of how to recognize it, as a simple PV or as a new V slot, is the Secondary question, pending the outcome of the first.) Also, perhaps a pointer on that page to this discussion may be all that's warranted. instead of restarting a discussion thread there. Kevin 17:10, 22 September 2015 (UTC)
I didn't see folks who thought archived scans were legitimate sources of a PV, who also objected to a new Verification slot. Rather that folks who thought highly of online scans, didn't have an objection to continuing to use PV slots for this purpose. If consensus objects to the continued use of a PV slot for verification against an online scan, it's very possible that those who supported the use of PV slots, may then instead support the use of a new slot. Kevin 17:10, 22 September 2015 (UTC)

PKD Awards

I'm adding the last couple of years of this award and have a question for those who have entered it (and other such awards) in the past. If a title is awarded a "Special Citation", I would expect that they actually won it and not just nominated for it. But in all cases (except for the ones I entered), they've been entered as "nominated" for a Special Citation. These seems strange to me. How do others feel about it? Mhhutchins|talk 19:54, 27 September 2015 (UTC)

That's odd but consistent. Perhaps worthy of a query to the PKD Award group to see if they know of any historical reason to refer to Citations as 'nominations' instead of award? Kevin 23:18, 27 September 2015 (UTC)
I'm not sure if it's consistent. For 2015, there were six works nominated (announcement here). After the judging, one was given the award, another was given a special citation, and the other four are considered finalists. If we're going to say that the winner of the special citation was a nominee after the awards have been announced, then why shouldn't the award winner also be considered a nominee after the awards have been announced? Illogical, of course, but consistent with how category is defined in other awards. Why do we have an option to see who won this category if none are displayed (other than the two I've entered)? Why does the entry form allow someone (like I did) to say that there is a winner in this category? If it's determined that no work wins in this category, the software should be changed to disallow the entry. The larger question is why is this considered a category, like for example, the Novel, Novella, Novelette, Short Story, etc. categories for the Hugo Awards. It seems we're mixing our definitions of what is a category. For the PKD award, since there's only one category, we shouldn't have an option of "Winner", "Special Citation", and "Finalists". That's results, not categories. Mhhutchins|talk 00:35, 28 September 2015 (UTC)
I meant it was consistent only with itself. (All prior entries were consistent.) Kevin 17:19, 28 September 2015 (UTC)
It sounds to me like the "Special Citation" is a runner-up award. Thus it's better than being a finalist, but not as good as being a winner. That's "sort of" communicated in the way it's laid out on our award page, but it would be nice to be clearer about it. If you want, this year's special citation went to a friend of mine, and I could ask her what it says. Although I doubt it will say anything other than "Special Citation". Chavey 06:01, 29 September 2015 (UTC)

Deleting an author profile

My apologies if this isn't the best place to ask, but is it possible to remove an author listing from the ISFDB completely? I'm listed in the ISFDB from a story I had published online several years ago, but I'd rather not be, as I'd prefer not to be listed in any databases if possible. And if I can't remove it, can i at least delete the Date of Birth from my profile so this isn't listed publicly? —The preceding unsigned comment was added by MrFiction15 (talk • contribs) .

I don't see why we couldn't accommodate a request to remove birth month and day, however without knowing your name, it will be difficult to accomplish. You are welcome to email me at kevin.pulliam@gmail.com with the pertinent details and I will make the requested changes. We can also put a note in the record stating your objection to a detailed DOB. I recommend that you allow us to retain your birth year in order to let us disambiguate you from any later authors with a same or similar name. Thanks Kevin 17:28, 28 September 2015 (UTC)
I just responded to the same request on the Help page. Kevin, I'm not sure how we can note this on an author's summary page. Can you explain how to do it? It can be done on one of the Wiki comments pages, but no moderator checks those pages when working on edits to author data edits. (Or I don't.) Mhhutchins|talk 17:58, 28 September 2015 (UTC)
I abused the webpage field and added a webpage of "Author_Requests_No_DOB_and_No_Website_Links.com". It's abnormal enough it should catch any Moderators attention. I see that the DOB has already been removed. Due to the visibility and relatively modern publication where the work appeared, and the follow-on Anthology Reprint, I'm afraid that's the best we can do with the current architecture. Kevin 23:58, 28 September 2015 (UTC)
There was no question that we would ever consider removing the fiction record from the database. I'm not sure if the method you've chosen is sufficient to keep a moderator from accepting a change in the author data. It wouldn't show up in a submission to add data. I see that Hauck accepted an earlier submission editing this author profile. I wonder if it had a year of birth, which in my opinion should have been retained in the record. That is insufficient data to cause a security issue, and enough to create disambiguation if necessary. Mhhutchins|talk 01:25, 29 September 2015 (UTC)
Yes, it had. MrFiction15 expressly asked for the deletion of his DOB. I complied with his wishes. As in France it's a legal obligation to do so, it didn't strike me as an excessive demand.Hauck 14:26, 29 September 2015 (UTC)
I agree in general regarding deleting a fiction record in traditionally published material. However I think that some cases, we might be able to accommodate an authors request for total removal (reviews, essays, etc particularly if they were in a one-shot fanzine or similar, with out republication. The title might have been kept, with the authors name changed to 'uncredited' and a publication note that it was 'by request of author of TITLE'. Regardless it's a case by case question at best, and in this case there was no room for wiggling. Kevin 13:36, 29 September 2015 (UTC)

(unindent) Given the number of diverging opinions expressed above, I think we need an explicit policy re: this issue. I will be copying this section to the Rules and Standards page and adding my take on the issue. Ahasuerus 16:43, 29 September 2015 (UTC)

Main Page link to magazines and fanzines

On the Wiki Main Page, under "ISFDB Resources", the 4th link is about Magazines and Fanzines. However, those links go to the old Wiki pages for them, which aren't being maintained. It seems that they should probably point elsewhere, such as to the Magazine Directory. Chavey 06:17, 29 September 2015 (UTC)

Should non-genre magazines be marked "non-genre"?

We have a tag now to mark things as non-genre. It seems natural then that "non-genre" magazines should be marked with that tag, as done here. On the other hand, I can see an argument against this: The story being indexed IS genre. The help page on working with non-genre magazines is silent on this point (I doubt it's been updated since that tag was added). So what's a responsible editor supposed to do? Chavey 06:26, 29 September 2015 (UTC)

I don't believe they should be flagged for the reason you give. That might also encourage editors to update the pub records with non-genre contents. (Since we've added the tag, I stopped at least one editor from doing that.) Another reason is that I believe the non-genre flag should not be made available on EDITOR-typed records, just as it shouldn't be available for ART-typed records. (My opinion, of course.) And the reason the help page hasn't been updated is for the reason you cite. This is a relatively recent function. Mhhutchins|talk 18:27, 29 September 2015 (UTC)
I can see this going either way, and I'm OK with either determination. Options 1: Magazines Marked as "Non-Genre" are the magazines with only genre contents entered. Magazines not marked so, are the ones where we enter all contents, including nominally non-genre short fiction, etc. We place rules to this effect on the non-genre magazine page. Option 2: We remove Non-Genre as an option for record types (including magazine/editor records) for which it doesn't apply. No update to the help is required. - That said... the most intuitive interpretation of the presence of the Non-genre flag as an option, is that it should be applied to Non-Genre magazines. I believe I have marked a few that way myself. Kevin 23:25, 29 September 2015 (UTC)
I find myself being convinced by Mike's argument. For comparison, imagine that an SF author, one below the "threshold", publishes a collection with a single genre story in it. We enter the book, and only that one story. If we list the book as "non-genre", the book then appears on their bibliography below the line marked for non-genre stuff. This is wrong for two reasons: the only story in there belongs above that line; this author is below the threshold and hence shouldn't have anything listed under non-genre. On the other hand, if the book is listed as "genre", then it appears in the main part of the bibliography, but appears with only that one story. I think the second result is clearly what should happen. Applying the same policy to magazines gives Mike's recommendation. Chavey 03:18, 30 September 2015 (UTC)
Retrieved from "https://isfdb.org/wiki/index.php?title=ISFDB:Community_Portal/Archive/Archive37&oldid=411531"