ISFDB:Community Portal/Archive/Archive39

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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 January - March 2016

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

Expanded archive listing

Lovecraft beer!

I just stumbled onto these:

and thought some of you might be amused to consider ways the Rules of Acquisition could be applied to them. :-)

Happy New Year, everyone! --MartyD 00:07, 2 January 2016 (UTC)

The site asks you if you are 21 before it lets you proceed. Oddly enough, ISFDB turns 21 this year :) Happy New Year! Ahasuerus 00:58, 2 January 2016 (UTC)

James D. Ross

Based on Amazon reviews, James D. Ross' "Charlie Moon" mysteries contain ambiguous speculative elements: the reader can choose to believe that the spirit world with which one of the characters communicates is real. Would anyone happen to be familiar with the series? Ahasuerus 17:38, 2 January 2016 (UTC)

C. L. Moore's "Trysts in Time"

I accepted a Fixer submission to add a record for this publication, which is a collection of two stories. The first title is recognizable and has been merged. The second title, "Trysts in Time" isn't in the database, but it's very likely a retitled reprint of an earlier published story. The back of the book describes it thus: "a bored adventurer sets off through time . . . and finds more than he bargained for in a beautiful woman who keeps reappearing throughout all of history!" Does anyone familiar with Moore's work recall such a story? Mhhutchins|talk 04:45, 3 January 2016 (UTC)

According to Google Books, the title page says "Greater Than Gods and Tryst in Time". The title on page 55 also reads "Tryst in Time", which we have on file. Ahasuerus 05:17, 3 January 2016 (UTC)

Thanks. I'll correct the Fixer-submitted title to that shown on the title page. Mhhutchins|talk 23:03, 3 January 2016 (UTC)

Marcos Mongo

Will the editor who created the three chapbook records credited to Marcos Mongo please variant them (and their shortfiction content) to the actual author? If you're uncertain who the actual author is, they should be varianted to "unknown". Thanks. Mhhutchins|talk 05:14, 3 January 2016 (UTC)

Since the original submitter hasn't responded, I checked these out. According to Zauberspiegel, three were by Harry G. Watkins and one was by Klaus-Dieter Schmidt, so I set up pseudonyms for them. Chavey 02:35, 9 January 2016 (UTC)

Tthere were only three titles when I posted the message, and the next day all three of them were varianted to "unknown" (by an unknown editor), clearing the pseudonym. I'm not sure which you're talking about. Those three titles of unknown authorship are still in the db as being unknown. Mhhutchins|talk 03:56, 9 January 2016 (UTC)

When I went there, there were four chapterbooks (and associated short fiction) listed under Mongo: Zaou programmiert die Wachsfigur, Nandors Leichenbande, Zaou sucht die Erde heim, and Tribunal der Finsternis. According to the Zauberspiegel link above, the first three were written by Harry G. Watkins, so I varianted them to him, and they are currently on his page, as the first three chapterbooks by him. The fourth book, Tribunal der Finsternis, is claimed by Zauberspiegel as having been written by Klaus-Dieter Schmidt under the Mongo alias. I aliased that book to Schmidt. It has since been changed so it reads that it was written by Gordon Scott, which is (apparently) the canonical alias of Klaus-Dieter Schmidt. Chavey 08:48, 10 January 2016 (UTC)

Server downtime

The server will be brought down for maintenance at 9:30pm server time. Please note that the server is now on US Eastern Time, i.e. one hour later than what we are used to. A new patch will be installed during the downtime. Patch notes will be posted shortly thereafter. Ahasuerus 02:00, 11 January 2016 (UTC)

Everything should be back up and running. Ahasuerus 02:35, 11 January 2016 (UTC)

Publication Series enhancements

As per FR 842, a new field, "Transliterated Name", has been added to Publication Series records. It's a multiply occurring field, so you can add as many transliterations as necessary. The field's value(s) can be viewed vis mouse-over pop-ups on Title, Publication and regular/Advanced Search pages. Advanced Search has been modified to add support for this field. In addition, the regular Publication Series search logic has been modified to find publication series whose regular OR transliterated names match the value entered by the user. For example, if you do a search on "Biblioteka", the search results page now includes not only publication series like "Biblioteka Jaskółki" but also publication series like "Библиотека всемирной литературы".

A new cleanup report has been created and can be accessed by moderators starting tomorrow morning. It find publication series whose names contain Latin characters and which contain titles written in a non-Latin language. There are approximately 70 affected publication series and I expect to clean up most of them tomorrow. We will have to check with our Japanese-savvy editors to sort out the 10+ Japanese publication series that we have on file.

Finally, Edit Publication Series has been modified to disallow the creation of duplicate publication series names. There is a new cleanup report to find pre-existing ones.

As always, if you find anything unexpected, please post your findings here. If everything looks OK in the next day or two, I can start working on making similar changes to publishers. Ahasuerus 03:39, 11 January 2016 (UTC)

PulpTales Press

It looks like I have some cleaning up to do, and as I get my life back in order I would like to create a series like this for Pulp Tales Press when I have the time. Somebody else started the Adventure House parent series and I've been adding on to it since I started contributing to this site. I can't help but think that a parent series and such would be useful to locate Pulp Tales Press books. Not their irregular magazines, or their anthologies, just their facsimile reprints as they seem to be second only to Adventure House in reprinting old pulps and digests. There are a couple of other publishers, but somebody else can do those, or they can be left for later. I'm not sure that I'm on the right page to ask this question, but, if so, somebody could drop me a note as to whether or not I should do this. MLB 08:20, 11 January 2016 (UTC)

Japanese publication series

If anyone can determine the original Japanese names of the following publication series:

could you please update the data? Also, if you determine that the names of some of these publication series were originally spelled using Latin characters, please post your findings here and I will remove them from the cleanup report. Ahasuerus 17:19, 11 January 2016 (UTC)

Hayakawa SF and Hayakawa SF Shirizu are the same thing. "Shirizu" is just a (wrong) romanization of "series". The name of the series is ハヤカワ・SF (Hayakawa SF). Working on the others. ···日本穣 · 投稿 · Talk to Nihonjoe 21:19, 11 January 2016 (UTC)

Okay, finished through Sōgen Suiri Bunko. I'll do the others tonight or later today. ···日本穣 · 投稿 · Talk to Nihonjoe 21:49, 11 January 2016 (UTC)

All completed. Most are awaiting approval. ···日本穣 · 投稿 · Talk to Nihonjoe 22:26, 11 January 2016 (UTC)

Approved, thanks! Ahasuerus 22:41, 11 January 2016 (UTC)

I looked them over and apparently I am too late but saw no glaring issues. Yay! We now have transliterations for pub series too. I wonder if we ought to have transliteration labels too (so we can know what sorts of transliterations we have). There are different methods of transliteration within a script like Latin and I am sure you can imagine there are other transliterations like into Japanese kana and Cyrillic, etc. Thanks! Uzume 04:41, 12 January 2016 (UTC)

We had this discussion back when the first "transliterated" field was implemented. The (tentative) consensus was documented in Template:AuthorFields:TransLegalName, which basically says that multiple transliterated values should be primarily used for "multiple competing Romanization schemes" and for languages which use "multiple scripts" (Japanese, Serbian, Azerbaijani, etc.) Now that we are in the process of implementing additional "transliterated" fields, we may want to move this explanation to a separate Help page and link to it from field-specific Wiki templates.

I should note that the issue of using these fields to enter other types of transliterations (kana, Cyrillic, Arabic, etc) was mentioned. However, there was little support for it since it was felt that Romanization would be sufficient for our purposes, especially since non-Latin titles are already entered using the original script. Of course, we can always revisit the issue. Ahasuerus 16:10, 12 January 2016 (UTC)

This becomes more of a concern when deciding how to sort, e.g., official/original Japanese (i.e., names, titles, etc.) cannot normally be collated (even by native speakers) without some form or transliteration (usually to one of of either hiragana or katakana). I believe when we start to consider native canonical authority control (e.g., authors and other contributors, subject headings, etc.), we will want separate language/script based directories. For example, how does the magazine ja:奇想天外 fit into our magazine directory? Remember magazines are title records and you are already claiming we can/should be entering such things in native/original script (I know you told me that we are not ready for native canonical authors yet; perhaps that has changed?). Uzume 19:36, 12 January 2016 (UTC)

Not yet. I am currently working on adding transliteration support to publishers, then it will be series, titles and authors. The last two will present certain technical challenges, but nothing insurmountable, I hope. Once that has been done and the publisher/magazine/author directories have been sorted out, we will be able to convert author names to their original script. Ahasuerus 22:07, 12 January 2016 (UTC)

I do not see an entry in the magazine directory for 奇 (the Japanese would not use this either though I am not sure what the Chinese do with their magazines perhaps they collate by radicals or something) or the kana き or キ (the Japanese transliterate the title 奇想天外 to either hiragana きそうてんがい or katakana; if you go to the Wikipedia article I linked to you can clearly see both 奇想天外 and きそうてんがい at the beginning—the transliteration is there to specify its pronunciation and collation). Uzume 19:36, 12 January 2016 (UTC)

I agree: it would be good to have some way of specifying the "sort field" for non-Latin character entries such as Japanese, Chinese, Korean, Cyrillic, and so on. One of the transliteration entries could be used for that, but it would need to be specified in case there was more than one transliteration. ···日本穣 · 投稿 · Talk to Nihonjoe 19:52, 12 January 2016 (UTC)

An interesting point. My first reaction is that there may be ways to address this issue without creating a "preferred transliteration name" field. For example, we could add all transliterated names to our main (Latin) directories as long as they start with two Latin characters. We could also create additional (Cyrillic, Japanese, etc) directories, which will automatically list primary and transliterated author/magazine/publisher names as long as the first two characters follow certain rules, e.g. they belong to the Cyrillic alphabet.

However, let me first ask you (plural "you") this: can you think of any other scenarios which may require a strict "sorting order" for names, thus necessitating a "preferred transliterated value" field? Ahasuerus 22:07, 12 January 2016 (UTC)

I am not sure we necessarily need a preference as per se. Like you mention nothing keeps us from having a Japanese magazine with kana transliterations and Latin transliterations from appearing in both kana-based directories and Latin-based directories (and that goes for non-Japanese works, etc. too so long as the transliteration collation fields exist/are filled in). Any preference would sort itself out over time as the records get updated (so I can for example see a preference for Japanese authors and titles to be in kana-based directories but for individual cases that need not be true). My point is, right now there is no really good automated way to determine what sort of transliteration an existing transliteration is so how do we know which directories to place it in? You bring up a good point about sampling the contents (are the characters Latin, Cyrillic, kana, or something else), however I can see situations where that might not work well. If we have a kana-based directory what do we do with Japanese magazines like ja:S-Fマガジン? If you look at the Wikipedia article there is the kana エスエフマガジン (where S-F is represented by the phonetics エスエフ). Also there are complications with sampling. I know there are at least four different types of kana in the Unicode maps (katakana, hiragana and their half-width variants come to mind). I suppose this is not that different that uppercase vs. lowercase, etc. but I can see the sampling getting complex and hard to maintain (we are going to need transliteration cleanup reports and/or mod warnings when we get submissions with multiple scripts in a single collation string; official strings probably will have cases with multiple scripts in them like the magazine I mentioned before). Perhaps the best solution would be have collating fields (including transliterations) that have a collation type flag but that collation type flag is automatically generated when entered and checked to be of one particular script (so collation methodology is automatically selected by script content and such entries are checked to be of only one type at entry). I wonder if there are cases where we might want/need multiple collations for a single script (I cannot think of such but I definitely do not know every language and script). Uzume 03:42, 13 January 2016 (UTC)

Interesting ideas, thanks. I will mull them over and will respond once I am no longer under the weather. Ahasuerus 15:17, 13 January 2016 (UTC)

Publication series -- the last 4

The following four publication series names remain suspect:

Biblioteka Fantastika. This is a Macedonia publication series. Unlike Serbian, which can use either Cyrillic or Latin, Macedonian is generally restricted to the Cyrillic alphabet.
Klassikē Bibliothēkē Neōn. Greek.
Sareboe Samalem. Sundanese.
Wu ye wen ku. Chinese.

Any additional information about these pub series would be appreciated. Ahasuerus 22:56, 11 January 2016 (UTC)

I submitted a correction for Wu ye wen ku. It was almost correct, but is now fixed. ···日本穣 · 投稿 · Talk to Nihonjoe 23:24, 11 January 2016 (UTC)

Thanks! Ahasuerus 23:40, 11 January 2016 (UTC)

I think Biblioteka Fantastika would be Библиотека Фантастика in Macedonian (македонски). ···日本穣 · 投稿 · Talk to Nihonjoe 23:31, 11 January 2016 (UTC)

It seems likely, but I hesitate to make the change sight unseen because it's conceivable that the publisher used the Latin alphabet in this case. We have a number of Japanese and Russian pub series whose names include words like "SF"... Ahasuerus 23:40, 11 January 2016 (UTC)

Yup. ···日本穣 · 投稿 · Talk to Nihonjoe 23:41, 11 January 2016 (UTC)

I checked with one of my students who speaks Macedonian, and he confirmed that it's always written in Cyrillic. I checked all of the thousand or so books from "Detska radost" that are in WorldCat, the publisher of that series, and looked at all of those where the title was given in Cyrillic, but none of them had a series title that was also in Cyrillic. Chavey 08:31, 13 January 2016 (UTC)

Thanks for checking! I guess one option would be to change the title to "Библиотека Фантастика" and add notes to the pub series record and the pub record to the effect that further confirmation may be needed. Ahasuerus 15:09, 13 January 2016 (UTC)

I think Klassikē Bibliothēkē Neōn would be Κλασσικē Βιβλιοτηēκē Νεōν in Greek. Not finding much about it, though. ···日本穣 · 投稿 · Talk to Nihonjoe 23:41, 11 January 2016 (UTC)

Wow we are starting to get some esoteric stuff cataloged now. Do we have any Aramaic fairy tales or the Coptic Demotic magical texts or the like yet? Anyway these are good signs of ISFDB becoming internationalized. Uzume 05:04, 12 January 2016 (UTC)

It's all Greek to me. ···日本穣 · 投稿 · Talk to Nihonjoe 05:29, 12 January 2016 (UTC)

Wilfried A. Hary = W. A. Hary

I don't understand why a pseudonym was created for this author when every work of fiction in the database is credited to W. A. Hary. Can the editor who created the pseudonym and variants please explain? This came up on a clean-up report because there are a dozen or so titles outstanding on the "pseudonym" summary page. Mhhutchins|talk 19:18, 12 January 2016 (UTC)

I see your point though that is not entirely true, e.g., Expedition der Ameisen . It should be noted the Wikipedia article de:Wilfried A. Hary and the VIAF record 69481816 both say Wilfried A. Hary. It should also be noted the Wikipedia article and this die Terranauten article both claim Wilfried Antonius Hary uses the pseudonyms of W. A. Travers and Erno Fischer. Uzume 19:45, 12 January 2016 (UTC)

This seems to be the form of his name chosen for his horror fiction. The science fiction was mostly written under the fuller name (but isn't entered at this point). And the pseudonym Erno Fischer was afaik only used for fiction set in the Terranauten universe. Stonecreek 20:43, 12 January 2016 (UTC)

The majority of Wilfried Antonius Hary's horror stories were published W. A. Hary. I was under the assumption that science fiction was published under his true Name but a quick scan showsas Erno Fischer (Terranauten and others), W. A. Travers, W. A. Hary, Wilfried Hary and Wilfried A. Hary. The mostly used alias seems to be W. A. Hary. And as I am the culprit to variant W. A. Hary titles to the already existing true-name entry: that wasn't a very good idea in order to keep variants down. I feel we should change W. A. Hary to be the main, canonical name. Erno Fischer is definitely NOT the author's name, it is Hary. JLochhas 21:07, 12 January 2016 (UTC)

I made submissions to credit Wilfried A. Hary with the outstanding W. A. Hary records. Uzume 21:16, 12 January 2016 (UTC)

It's better to canonize the fullest name, if there's substantial amount of work - and there should also be the occasional shortfiction under that name (apart from chapbooks). Stonecreek 21:20, 12 January 2016 (UTC)

I believe you said his SF work was under the fuller name but it is just not cataloged here much yet. Has he written more Wilfried A. Hary SF or W. A. Hary horror, or somethings else? Uzume 21:22, 12 January 2016 (UTC)

[unindent] With hopes that eventually the work attributed to his more complete name will be added to the database, I drop my objection to the parent/pseudonym relationship. And thanks for varianting the remaining records. Mhhutchins|talk 21:34, 12 January 2016 (UTC)

Cover images from Amazon

copy-paste by the writer 2016-01-13 from the original at User talk:Mhhutchins -Pwendt

For the Dell Yearling (imprint) edition of Peter Graves, 2nd printing 554604, i recently linked a cover image on the secure server (URL begins 'https') at Amazon, namely URL

https://images-na.ssl-images-amazon.com/images/I/51OFHnt89sL.jpg

ISFDB and my browser correctly processes that URL value in order to display the thumbnail cover image correctly for me. But that is not true of the footnote which reads "Cover art supplied by images-na.ssl-images-amazon.com" and incorporates a dead link. I guess this may even violate ISFDB agreement with Amazon.

Perhaps the database interface works entirely for the insecure server ('http') ecx.images-amazon.com alone. (I see that component of URL on your user page, where it may be interpreted as an example rather than a requirement. That is why I ask you in this instance.) --Pwendt|talk 22:13, 12 January 2016 (UTC)

"your user page" refers or alludes to User:Mhhutchins#How to link to images on Amazon's server.

"I guess" refers or alludes to the possibility Amazon requires a footnote with a functioning link. --Pwendt|talk 21:00, 13 January 2016 (UTC)

(unindent) That's curious. When I go to Amazon and pull up their page which contains this image, I see that it uses "ecx.images-amazon.com/images/I/51OFHnt89sL._SX338_BO1,204,203,200_.jpg" as the image URL. Do you recall where you found the "images-na.ssl-images-amazon.com" URL? Ahasuerus 21:13, 13 January 2016 (UTC)

I see that the first and last words of the filenames on the two servers are identical (51OFHnt89sL.jpg) and from apparent scuffmarks and discoloration I infer they are images of the same book.

Easily I can provide one of my sources, ShopSwap.com [1]. I believe that I found it on more than one page that is returned by Google search 'Peter Graves: an extraordinary adventure'

--serendipity, as my purpose was to find an edition that uses the subtitle (i didn't find one clearly) or to determine that the subtitle should be deleted from the database for now (i did so, 2016-01-06 16:10:58 TitleUpdate Mhhutchins Peter Graves: An Extraordinary Adventure). --Pwendt|talk 22:34, 13 January 2016 (UTC)

After checking various online discussions, it would appear that "images-na.ssl-images-amazon.com" may be owned and used by Amazon. If we could confirm that, then I could update the ISFDB software to credit Amazon for any images hosted by images-na.ssl-images-amazon.com. For now it would be best to use "images-amazon.com" links since they apparently have identical information and our software already supports them. Ahasuerus 23:56, 13 January 2016 (UTC)

One week later moments ago, I submitted a revision in favor of the current standard protocol and pathname for the example publication record P554604. Not yet approved. --Pwendt|talk 00:37, 22 January 2016 (UTC)

New users experiencing problems with account creation

FYI, it looks like the server upgrade that was performed by the hosting company on New Year's Eve messed up more than we realized. New users trying to create ISFDB accounts are currently unable to have their e-mail addresses confirmed. I have started an e-mail discussion with Al. Ahasuerus 23:31, 13 January 2016 (UTC)

Update: Al has fixed the problem. New editors should be able to receive e-mail confirmations going forward. Ahasuerus 03:02, 14 January 2016 (UTC)

I'm also unable to edit my own user page; I get a notice saying "Permission error: You do not have permission to do that, for the following reason: You do not have permission to edit pages in the User namespace." Not sure if it's related to the server upgrade, but I was affected by the email issue and it seems odd that I can't edit my own page. S. Qiouyi Lu 16:11, 14 January 2016 (UTC)

At one point we had a fairly serious problem with spam, so we tightened up Wiki posting permissions. A new user can only edit a limited subset of Wiki pages until his or her Wiki edit count has reached a certain number. I don't want to post the actual number in case our spammer friends are reading this, but it's not very high. I would suggest giving it a few days to see if the issue resolves itself once your edit count is high enough. Ahasuerus 17:07, 14 January 2016 (UTC)

Self-advertising (reprise)

Further to discussion last year regarding a business card to hand out at our local book sale, here's what I've opted for (without replicating centering and fonts). I figured I'd leave images off to avoid copyright issues, and colour to simplify printing if it were ever done commercially.

www.ISFDB.org

The Internet Speculative Fiction Database

A community effort to catalog works of science

fiction, fantasy, and horror.

Linking author, title, publication, awards, magazine

content, anthology and collection content.

Doug 14:02, 14 January 2016 (UTC)

New volume of critical essays about Heinlein

Have you worked yet on the new volume of critical essays about Heinlein? The publisher is Salem Press. The editor is Rafeeq McGiveron. It appeared in September 2015. I have an essay in the early sections of the collection about the critical reception of Heinlein's work, and would like to see it listed here. Thanks for your help. DMH Donald M. Hassler

Done, result here. Note that you may try to enter such a book by yourself, it's quite straightforward. Hauck 18:24, 14 January 2016 (UTC)

Edward E. Kramer as "Nathan Elliot"

I've come across what is very likely an incorrectly attributed pseudonym that needs a little untangling. I propose removing the pseudonym "Nathan Elliot" (one t) for Edward E. Kramer – our records, probably erroneous, currently show it has been used only once by Kramer in the unverified publication More Phobias: Stories of Unparalled Paranoia for the story Jamie's Demon. However, "Nathan Elliott" (two ts) was a pseudonym used frequently by Christopher Evans, and both Wikipedia and the Writers of Wales Database show him to have written a story with this title in the same year under the name Nathan Elliott. I think these two sources provide more reliable information that what we currently have as evidence for Kramer/Elliot (which appears to be nil). Unless other editors know of a reason why the records should stay as they are I propose making the change in a few days. Thanks. PeteYoung 14:29, 16 January 2016 (UTC)

I wish more more editors would add their sources for author information to the applicable author wiki page. The pseudonym is actually 'Eliot' (one 'l' and one 't') which matches the Locus and OCLC credits. While it's possible they both drew from the same incorrect source, I would recommend keeping the 'Eliot' credit (even if you change the pseudonym parent). -- JLaTondre (talk) 16:18, 16 January 2016 (UTC)

I'm kinda wary about changing the pseudonym to Evans. All of the "Nathan Elliott" stories appear to be science fiction novels from the 1980s. This 1995 "Nathan Eliot" short story is horror, appearing in an anthology co-edited by Kramer. Did Evans write any horror at all? So we're comparing a single horror story of the 1990s to a series of science fiction novels from the 1980s which are differently credited. Because the names are somewhat common, I think it's going out on the limb to say they're by the same author. The Wikipedia article and Wales databaase don't appear to be definitive sources, and may have simply jumped to the same conclusion as you, that "Elliott" is "Eliot", and may have sourced each other for the data.

If we can't find a reliable source attributing the pseudonym to Kramer, I would suggest removing the relationship and keep the story credited as published, with a note. And I agree, that it would be great if ISFDB editors were required to provide sources for pseudonym attributions on a wiki author page. Mhhutchins|talk 18:52, 16 January 2016 (UTC)

I'm trying to get in touch with Christopher Evans via Paul Kincaid, who may be a mutual acquaintance. A word from Evans either way should settle this. PeteYoung 00:58, 17 January 2016 (UTC)

Christopher Evans has confirmed by email that 'Jamie's Demon' is not by him. Note added to the story, and thanks for the correct feedback, guys. PeteYoung 12:56, 20 January 2016 (UTC)

"Top 50 Forthcoming Novels of Interest" fixed

"Top 50 Forthcoming Novels of Interest" has been fixed and prettified. Unfortunately, it's based on limited data since our users tend to be interested in already published books rather than forthcoming books. Ahasuerus 01:17, 20 January 2016 (UTC)

Delete Author Entry

I would like to have the mentions using my name on this site deleted and thus my entire entry deleted: I am not a public figure, the publications cited are minor contributions to minor fanzines and there is no public clamour to discover such material, and I never asked to have a presence here. Failing that, I would like to have my birth year removed from my record: it is materially injurious to my finding employment. I have searched for the method to accomplish these goals and found an archived discussion of this subject that astounded me: the mere fact that a piece of information exists on the Internet somewhere should not convey the right to collect and publish such information in a single location against the express wishes of the person who is the subject of such a collection. I hope that you will take my employment situation into account, and also reconsider the larger policy of ignoring author requests regarding their entries. —The preceding unsigned comment was added by Jgelb (talk • contribs) .

I'd disagree with this commentary: publishing inevitably leads any person to become a public figure. I personally wouldn't work for anybody who rejects a search for a job on grounds like that. Also, we don't publish the date of birth, only the year. That's not concrete enough to identify any person, unless it's a really uncommon name. We could move the year to the wiki pages instead, though. Stonecreek 16:25, 20 January 2016 (UTC)

Since the entries don't show any contents (outside of the titles of entries and when and where they were published), I'm not sure why someone would care about "minor contributions to minor fanzines". If it's the entry I think it is, I would be less worried about people finding the page here than people finding her fan page (though it doesn't seem to be anything to worry about unless her potential employer is a schmuck who hates all things fandom). ···日本穣 · 投稿 · Talk to Nihonjoe 17:22, 20 January 2016 (UTC)

(unindent) A couple of general comments about the way the ISFDB works.

Like other major bibliographic sites (WorldCat, Goodreads, etc), we catalog published works regardless of the presence or absence of public demand and/or authors'/editors' requests. For example, here is what Goodreads' Help pages say on the topic of removing books based on author request: "Deleting published books from our system is against policy. Goodreads is striving to be a complete database of all published works, including works that are out-of-print."
When it comes to biographical data, we use publicly available sources. This means, e.g., that we do not identify undisclosed pseudonyms even when we, as individual editors, are aware of them.

The last time we discussed this issue, there appeared to be consensus that we should replace exact dates of birth with years upon author's request, but a few other things were left open-ended. Now may be a good time to codify everything and make the policy available on a separate Wiki page. 22:09, 20 January 2016 (UTC)

I agree. The policy should be documented, but having a separate Wiki page wouldn't be necessary. We have a Policy notice. Wouldn't it be just as good to document it in a new section of that page? This would avoid the need for searching or directing users to a variety of pages. Mhhutchins|talk 00:04, 21 January 2016 (UTC)

As with Goodreads, I don't think we should delete references to basic data, including appearances in fanzines. I would be a little more willing to consider deleting birth years, in case someone is concerned about age discrimination (which is real). But in this case her birth year is also published in her entry at fancyclopedia, so having us remove it isn't going to help. I'll also mention that as a DUFF winner, and three-time Guest of Honor (Concave, Baycon, and Capricon), she IS a public figure. Chavey 05:55, 21 January 2016 (UTC)

Let's say that we allow authors to delete all or part of their bibliography. Even though I do not believe for a second that will ever happen, here's a hypothetical question: how do we know if the person making the request is actually the author? There is no way of verifying the request is legitimate without requiring that the person provide certain information that in itself will be a breach of privacy. Ironic, isn't it? Mhhutchins|talk 01:32, 22 January 2016 (UTC)

I am very much against letting us get strong-armed into changing things based on individual wants/pleas even when privacy is concerned. If we go down this slippery slope, as Michael pointed out, we will need an authentication system (we cannot let just anyone tell us to remove things) and a way to police such records so the data does not get accidentally reintroduced. I believe we would do far better to agree what data we collect and how we collect and retain it and stick to that. Now if this prompts us to reconsider what we have decided to collect, that is fine. Right now we also have contact information in the form of email addresses. To me these are about the only questionable items we collect (and they are pretty pointless for dead authors unless we are listing email addresses of some authorities besides the authors). Of course the collection methods should also be documented (we should not publish things given to us privately in confidence and we are not going to hire private investigators to collect such items but if they are publicly known, so be it; such things cannot really be retracted). Uzume 01:00, 23 January 2016 (UTC)

I agree that the email address field is pushing the boundaries of propriety. I don't think we need to be providing that information to people. Providing a link to their website(s) should be enough, and most websites will have one or more contact methods listed on the site. I support simply dropping that field in the table. ···日本穣 · 投稿 · Talk to Nihonjoe 01:17, 23 January 2016 (UTC)

Well websites can be more than just an author's website. I believe most of those links are actually to biographies, bibliographies, and authority control sites rather than personal author websites (though we do have those too and they can be useful in providing biographic and bibliographic information). The thing about email addresses though is that they are normally easily changed and disabled, etc. It is possible to change your name and/or the names you publish under but how does one change their birth or death information? This is why we collect it to help identify contributors so we can credit them accordingly (you get all the glory and blame from whatever you publish). If we are using email addresses to contact contemporary authors and we want to keep such around, I recommend it not be part of the DB proper and instead say a list on a wiki page here or the like then we can have different collection and retention rules for that (in a similar vane, I can put whatever I want on wiki pages here, e.g., under my user space, so long as they are not terribly profane, libelous, fraudulent, etc. and at least somewhat on topic). Uzume 01:46, 23 January 2016 (UTC)

A little bit of background. ISFDB 1.0 was designed in 1995 when the Web was new. E-mail addresses had been around for a while while author-specific Web pages were very rare at the time. For example, when I asked Steve Miller's if he wanted me to put his Liaden Universe FAQ on a Web page, he wasn't even sure what a Web page was.

History aside, I think we want to keep e-mail addresses in the database for the following reasons:

Many authors explicitly say "You can contact me at name@domain.com" on their Web pages.
Our policy has always been to stick to publicly posted addresses. As Help:Screen:AuthorData says, "If the author's email address is public, i.e. stated on the author's Web page in plain (unobscured) text or otherwise publicly posted, enter it here."
I don't recall author complaints about this field. Occasionally authors create submissions when their e-mail address changes or becomes inactive.
Moving e-mail addresses to the Wiki would be against our overall development philosophy, which is to move all biobibliographic data from the Wiki to the database, not the other way around.

Ahasuerus 02:45, 30 January 2016 (UTC)

I totally agree with retaining the current policy. Mhhutchins|talk 04:16, 30 January 2016 (UTC)

I too am not in favor of changing our policies in this regard but if we are to (re)consider our policies with regard to privacy concerns I just thought I would mention where I felt our current policies were perhaps weakest in this regard. Uzume 16:04, 31 January 2016 (UTC)

Robert Arthur, Jr. is NOT Robert Arthur

Editor Calion found out about this mix-up. There was actually only one piece of shortfiction credited to Robert Arthur, Jr., but I guess many of the others as by Robert Arthur are really by the Jr. Is anybody able and willing to sort the apples from the pears, for I am not able to do it. Stonecreek 09:47, 21 January 2016 (UTC)

And there's Robert Andrew Arthur, which may be a pseudonym of Robert Arthur, Jr., or still another person. Stonecreek 09:51, 21 January 2016 (UTC)

Unfortunately, I know very little about this area (the anthologies and their contents are only barely spec-fic), so I can't help. But what I do know is that changing the published credit isn't the way to go about. (I guess we all know that except for the submitter.) Some of them are ghost-edited, so it's a safe bet to change them, since the books were never credited to "Robert Arthur" or Jr. I'll try to approach it from a purely technical stand, and let someone else do the bibliographic work. Mhhutchins|talk 01:39, 22 January 2016 (UTC)

Turned out easier than I thought. The submissions only changed the Hitchcock anthologies which were ghost-edited. There are still three anthologies explicitly credited to Robert Arthur as the editor. Someone will have to determine if it's really him or Junior. There's also one collection (Ghosts and More Ghosts) which Wikipedia attributes to Junior. But this collection contains stories in the Murchison Morks series which we have as written by not-Junior. Just to make it clear, this isn't father and son. They were both born in 1909, adding more headache to separating their bibliographies. Mhhutchins|talk 01:54, 22 January 2016 (UTC)

More trouble: In this memoir by Junior's daughter, he is the author of Ghosts and More Ghosts which means the Murchison Morks stories are his as well. Also, the wikipedia page we have linked to Robert Arthur mentions nothing about him writing all of those stories for the pulps and the slicks in the 1930s and 1940s. Those stories are almost certain by Junior, whose Wikipedia page explicitly calls him a "speculative fiction writer" and provides a list of many periodicals which we have indexed here and attribute to non-Junior. Mhhutchins|talk 02:01, 22 January 2016 (UTC)

I've come to the conclusion, after quite a bit of research, that all records in the database are by the same author, whether attributed to "Robert Arthur", "Robert Arthur, Jr." (only one story in a 1933 issue of Amazing Stories), or "Robert Andrew Arthur" (a 2013 reprint of a 1954 story originally credited to "Robert Arthur"). What screwed it up was someone providing data (based on the Wikipedia page, I guess) for Robert Arthur, a Hollywood producer, not the same person who was the pulp writer and ghost-editor for Hitchcock, who was a Junior, but published all but one story as just "Robert Arthur". It's all there in his daughter's memoir. Unless there's objection in the next day or so, I'm going to merge these authors. Mhhutchins|talk 03:19, 22 January 2016 (UTC)

Sounds good to my ears. My guess would have been that the Hitchcock anthologies might have been by the movie Arthur, but a literary person like the other Arthur is far more reasonable. Thanks, Michael! Stonecreek 10:18, 22 January 2016 (UTC)

Agreed. I also looked into this a fair bit and I too would go about changing Robert Authur to be the canonical name (copying data from Jr. and making Jr. a pseudonym) and update the Hitchcock variants to credit Robert Author (and clean up the few outliers you mentioned). If after all that, the director still deserves some accreditation for something here, I say we make a new canonical name for him (adding dates or something). Uzume 13:25, 22 January 2016 (UTC)

I think this is wrong. Robert Arthur, Jr. was born November 10, 1909 and died May 2, 1969 and wrote various Hitchcock things, in particular the Three Investigators series. Robert Arthur Feder, born November 1, 1909 and died October 28, 1986, was a film producer who also wrote the Murchison Morks series. At least that is the assertion of Martin H. Greenberg, who, in Isaac Asimov Presents the Golden Years of Science Fiction (1979), Vol. 2, p. 65, says, "Robert Arthur (Robert A. Feder) is a neglected writer of sf and fantasy, best known as a television and radio producer and scriptwriter. This is unfortunate, because he produced a number of excellent stories, many of them outside the sf magazines. In the science fiction field his reputation resides with his "Murchison Morks" series." However there is some confusion as to which Arthur is which even in this book, because his birth and death dates are given (1909–1969). These dates cannot have been input by Greenberg, however, because he refers to Arthur in the present tense, which he does not do for deceased authors. However however, the fact that it looks like Robert Arthur, Jr. wrote Ghosts and More Ghosts, which includes Murchison Morks stories, seems to count against Greenberg and for your interpretation (and if Murchison Morks was indeed written by Robert Arthur, Jr., I didn't find out about this mixup on ISFDB; I created it). Calion 16:46, 22 January 2016 (UTC)

If Junior's daughter said he published the collection Ghosts and More Ghosts, and if that collection contains the Morks stories, then it follows that Junior wrote the Morks stories. Greenberg had to have been wrong when he gave the author as a pseudonym of Robert Feder. Ironically, Greenberg was always being confused with another Martin Greenberg, so you'd think he would have been more sensitive to avoiding such confusion. I'm going to merge the author records. Thanks. Mhhutchins|talk 20:07, 22 January 2016 (UTC)

It was staring us in the face the whole time. This page was linked to Arthur's page and if I'd taken a moment to read it, the decision to merge the records would have been more immediate. Regardless, the deed is done. Mhhutchins|talk 20:13, 22 January 2016 (UTC)

I'm the one who linked that page, but I don't see any slam-dunk evidence on it. Is it that it supports him as author of Ghosts and More Ghosts? Regardless, it's starting to look at least likely that there is only one Robert Arthur, author. I wish I knew where Greenberg got his information. I'd say sorry for starting the confusion, but I think I can be forgiven for taking Greenberg as an authoritative source. Calion 21:31, 22 January 2016 (UTC)

I read that page as well as the daughter's page and why I said I agreed that everything basically should be accredited to one individual. Once that is understood, it is a simple matter to choose the most used named. It looks great—thanks Michael! Uzume 00:48, 23 January 2016 (UTC)

E-mail and weather problems

Our e-mail server is once again having problems. I have escalated the ticket to Al.

Also, please note that a significant part of the East Coast of the United States is about to be hammered by a major blizzard. Widespread power outages are expected, which can cause some editors to be offline for a while. Ahasuerus 17:36, 22 January 2016 (UTC)

The e-mail server is back in business. Ahasuerus 17:20, 25 January 2016 (UTC)

New editors not supplying a contact email

I thought new editors were required to supply an email address. This one needs to be made aware of his talk page and I have no way of contacting him. Mhhutchins|talk 05:08, 23 January 2016 (UTC)

New editors have to supply a valid e-mail address (and confirm it) in order to be able to edit the Wiki. However, our e-mail server has been having problems lately, so they are not getting confirmation e-mails -- see above. Ahasuerus 05:18, 23 January 2016 (UTC)

But they can edit the database without responding to a confirmation email? Strange protocol, IMHO. Mhhutchins|talk 05:39, 23 January 2016 (UTC)

It greatly reduces the number of spam edits, which is a good thing :) Ahasuerus 05:41, 23 January 2016 (UTC)

Spam edits of the database? Then that makes it even stranger that they're not required to respond to a confirming email. Wouldn't that increase spamming? Maybe I'm missing something here. Mhhutchins|talk 17:07, 23 January 2016 (UTC)

Sorry, I meant "spam edits" on the Wiki side, not on the database side. We had a big problem with spammers a while back and the implementation of e-mail verification helped get them down to one or two per day. Ahasuerus 17:42, 23 January 2016 (UTC)

I'm aware of that. A few still get through which I delete when I come across them. I guess you're saying that there is a system to combat spamming on the wiki, Mhhutchins|talk 02:54, 24 January 2016 (UTC)

That's right, the current system was originally put in place in order to make it harder for spammers to post spam on their Talk pages. They can still do it -- if they go to the trouble of entering a valid e-mail address, waiting for the verification e-mail to arrive and clicking on the verification link -- but it slows them down and makes the spamming process less efficient. Spamming is a very big business (hundreds of millions of dollars annually), so anything that slows them down makes us look like a less attractive target. They just move on to other, juicier targets. Ahasuerus 13:40, 24 January 2016 (UTC)

but it's currently not working because it allows persons to edit the database without doing an email confirmation. Mhhutchins|talk 02:54, 24 January 2016 (UTC)

The e-mail server component of the ISFDB (i.e. the software that sends e-mails) has been having problems since the hosting company upgraded the firmware on 2015-12-31. This means that new editors can't verify their e-mail addresses and therefore can't edit the Wiki. They can still create submissions, though. Granted, we can change the submission mechanism to require editors to have a verified e-mail address on file, but then any time we have e-mail server problems new editors won't be able to create submissions. That seems like a bad trade-off. Ahasuerus 13:40, 24 January 2016 (UTC)

Putnam = G. P. Putnam's Sons

I plan to merge these two publishers into a single publisher named G. P. Putnam's Sons. Although "Putnam" is printed on the spine of the dust jackets, the publisher as given on the title page has always been "G. P. Putnam's Sons." If any editor has primary verified records under Putnam, and doesn't want them to be part of the merged publisher, please change them to a unique publisher name of your own creation. Once I've made the merge in a few days, after any discussion here, you can change them back to Putnam. Non-moderators, let me know what publisher name you've changed them to, and I will do a submission to change it back to Putnam. There are currently now only 40 or so records under "Putnam" which have been primary verified. Mhhutchins|talk 02:44, 24 January 2016 (UTC)

ISFDB in the News

The online fanzine File770 recently published an article New Tiptree Award Website Looks Great. Mike Glyer gives a couple of reasons why that award site is great, with one particular note:

The site’s crown jewel is the searchable James Tiptree, Jr. Award database, which not only 
returns the names of winners and honorees, but links to their author websites, and to their 
bibliographies on the Internet Science Fiction Database.

The first commenter agreed that linking to us was a cool feature :-) Chavey 07:00, 24 January 2016 (UTC)

Great! Christian Stonecreek 20:29, 24 January 2016 (UTC)

Non-genre work by fictional character from genre works -- in/out opinions solicited

I have a very odd case that we're unlikely to see again. I'm interested in feedback on inclusion/exclusion from anyone having strong feelings about it, one way or the other. IMO, it's not worth an R&S debate -- I don't think we need a rule for it.

I've recently recorded a series of stories, plus a collection, about the adventures of a bridge-playing robot, Chthonic. These are written by a bridge guy, Danny Kleinman, and a computer guy, Nick Straguzzi. Although the primary purpose of these stories is the bridge, there's no question in my mind that these are "in" according to the rules of acquisition. But now here's what may be a unique situation:

There is a book, Human Bridge Errors: Volume 1 of ∞ (Master Point Press, 2007). This is a true bridge book. I consider it non-genre. It uses fictional settings and characters from the Chthonic stories to lay out deals and make its points, but it's not telling stories -- it's instructional; I personally would classify it as non-fiction. The kicker is, it's purportedly "Collected and Analyzed by Chthonic", with Kleinman and Straguzzi as the "editors". Chthonic has an "Author's Introduction", prior to a "From the Editors" credited to Kleinman and Straguzzi, and the entire book is written in the first person, as Chthonic. (The Library and Archives Canada Cataloguing in Publication info has Kleinman and Straguzzi as the authors, FWIW.)

If it were to be "in", I think I'd make a higher-level "Chthonic" series, put this book into it, and then make "The Chthonic Bridge Chronicles" (containing the SF works) a sub-series.

Does anyone have strong opinions about whether this should be in (as non-genre, unless someone wants to argue that it's spec-fic) or out? --MartyD 16:19, 24 January 2016 (UTC)

Out, as an integrist, I think that we've got far too many "peripheric" texts already entered (I've just multi-moderated a bunch of non-genre short stories by Atwood, explaining probably this reaction) from Aesopian fables to regecy romance via Shakespeare plays and comic books. Hauck 16:35, 24 January 2016 (UTC)

Out, if you chose the NONFICTION category. My personal choice, though, would be to include it as a NOVEL. There's only the framing story that's speculative, but that is enough to my taste. This NOVEL set in Nazi Germany also is only in because of its framing story told by Death. Christian Stonecreek 20:26, 24 January 2016 (UTC)

It's non-speculative non-fiction by non-genre writers. Three nons and you're out. Mhhutchins|talk 21:51, 24 January 2016 (UTC)

Dragons of Summer Flame

This title has "Dragonlance Chronicles Volume 4" on the title page, but we have it listed as part of the series Dragonlance: Second Generation (which actually only has one book in it). Why don't we move it to be part of Dragonlance Chronicles? ···日本穣 · 投稿 · Talk to Nihonjoe 19:06, 25 January 2016 (UTC)

You can do that if there is sufficient evidence to confirm that it should be moved to the other series. Mhhutchins|talk 20:22, 25 January 2016 (UTC)

Okay, I submitted it. Since every edition (hardcover and paperback) I have seen has "Dragonlance Chronicles Volume 4" on the title page (I have seen about 5 or so different ones), that's good enough for me. I have no idea where the idea came from that this was part of the Second Generation series (which isn't actually a series). ···日本穣 · 投稿 · Talk to Nihonjoe 20:26, 25 January 2016 (UTC)

Visco is no more?

It appears that Visco has gone kaput. When the records linked to Visco are come across, please re-link the images to those on Galactic Central. Mhhutchins|talk 19:59, 26 January 2016 (UTC)

If anyone is looking for another project: They can be found by doing an Advanced Search, using the Publication Search Form, and searching the Image URL field for sfcovers. -- JLaTondre (talk) 00:01, 27 January 2016 (UTC)

A brief look at the search results counts 1400+ affected pubs as of today. Uzume 02:56, 28 January 2016 (UTC)

Visco is now archived on Philip Stephensen-Payne's website: http://www.philsp.com/visco/index.html. In his announcement he added that he and Terry Gibbons have neither the time nor inclination to do any further work on the website but think it's worth preserving. PeteYoung 05:21, 28 January 2016 (UTC)

So is it possible to write a script to rewrite all of these links without any manual submissions? Mhhutchins|talk 06:59, 28 January 2016 (UTC)

Sorry, I missed the question when it was posted. I'll take a look. Ahasuerus 18:03, 3 February 2016 (UTC)

Randomly checking a couple dozen images suggests that the site structure was preserved during the migration. Let me try to convert our links real quick. Ahasuerus 18:32, 3 February 2016 (UTC)

Done. Ahasuerus 20:06, 3 February 2016 (UTC)

Great. Thanks. I see that they're credited to Galactic Central, which is fine by me, as long as the image loads. Thanks again. Mhhutchins|talk 21:31, 3 February 2016 (UTC)

Submission listing incongruity

This is hardly a high priority but I thought I would report it as it seems to be aberrant behavior of the Python code. The minor issue is that when viewing lists of submission records (via myrecent and recent) it seems the displayed "Subject" varies from current old value to submitted new value based on the submission type, e.g. PubUpdate and MakeVariant always choose the proposed submitted title, however, TitleUpdate always choose the old original title. I did not look into every submission type. It seems to me these should be more consistent. As a side note and in terms of considering which to standardize on, using the old value maybe more interesting when viewing submission records after successful moderation (because the diff won't show the old values after the submission is committed). Uzume 20:57, 27 January 2016 (UTC)

Sounds reasonable; FR 849 has been created. Ahasuerus 20:52, 3 February 2016 (UTC)

Arthur H. Landis / Camelot

Putting this here because I have no personal knowledge of the works in question and several verifiers of pubs may have a relevant opinion. I've been addressed on the Fictionmags list with a query about Arthur H. Landis, specifically as to why his novel Let There Be Magick! is not included under the fiction series 'Camelot'. A title note for A World Called Camelot states "An earlier and somewhat different version of this novel was published as a serial under the title "Let There Be Magick" with the by-line of "James R. Keaveny", and is copyright, 1969, by Camelot Publishing Company." I'm just checking first if there is a reason why this series does not include Let There Be Magick! or if it's an oversight that needs to be corrected. Thanks. PeteYoung 05:02, 28 January 2016 (UTC)

It's easy to fix. Just change the variant links of the serial parts to the title record for A World Called Camelot. We allow that serialization sometimes means that the work may have been revised or expanded for book publication. Mhhutchins|talk 07:02, 28 January 2016 (UTC)

Curiously, SFE claims that Home – To Avalon (1982) is part of the same same series while Landis's (seemingly well-informed) Wikipedia article states that it was merely "thematically similar".

Although I have all 4 books in my collection, I haven't read them and can't get to them right now. I'll send Dave Langford an e-mail to see what their archives says. Ahasuerus 15:23, 28 January 2016 (UTC)

Maybe we're looking at two different pages, but the SFE article you link states that Home To Avalon is the only Landis novel not in the series. I'm going to variant the serial to the book publication title. Mhhutchins|talk 19:00, 28 January 2016 (UTC)

I see that Dave has already updated Landis's SFE3 page. The previous version read:

He published there a four-part serial as by James R Keaveney, which became A World Called Camelot (September 1969-March 1970 COVEN 13 as "Let There Be Magick"; rev vt 1976) as by Landis, and was followed in the same series by Camelot in Orbit (1978), The Magick of Camelot (1981) and Home – To Avalon (1982).

Ahasuerus 19:46, 28 January 2016 (UTC)

PeteYoung asked me to drop by. I have a copy of A World Called Camelot which I can get to and am happy to look anything up, but I'm not sure I can add anything otherwise.--AliHarlow 10:48, 29 January 2016 (UTC)

New Publisher - Venture Press

A new UK-based SF/F publisher, Venture Press, was launched a few months ago. Amazon knows of more than 80 titles, but, unfortunately, almost none of them have ISBNs associated with them. Fixer won't be able to process them until we add support for "third party identifiers" (in this case ASINs), so for now this publisher will have to be handled manually. Ahasuerus 23:56, 31 January 2016 (UTC)

I have always wanted to make large improvements to the web API (e.g., get any of the records and search not just by ISBN, etc.) but offline issues (probably the biggest is unstable work conditions) keep becoming an impediment and it is hard to get back into coding here (I need to rebuild my workstations/work environment as well as my development server). Being sick for the last week has not helped either. That said, things like OCLC and LCCN IDs, etc. should also help with many older titles that Fixer really is not designed to find and process. Uzume 15:01, 2 February 2016 (UTC)

Actually, Fixer has a number of APIs (and local databases) which handle pubs without ISBNs. The database of Kindle books without an ISBN alone contains more than 750,000 ASINs. Fixer's problem is that he has no way of telling which Kindle books are already in the ISFDB database. The situation will change once we add "third party identifier support" to the ISFDB software. Ahasuerus 17:02, 2 February 2016 (UTC)

Container titles in the Content section of Edit Publication

As we all know, Edit Publication won't let you edit a Content item if it is associated with 2+ publications. That's fine, but the software also prevents you from editing "container" titles (collections, anthologies, omnibuses, chapbooks) even if they do not exist in other publications. It seemed like a prudent precaution back when the "yellow" functionality was implemented, but sometimes it forces you to submit additional edits, which can be a pain when you are trying to make hundreds of changes.

Can anyone think of a reason not to change the software to allow the editing of "yellow" container titles? (As long as they don't exist in other pubs, of course.) Container titles will still be colored yellow to remind us that they are "reference" titles. Ahasuerus 16:57, 1 February 2016 (UTC)

I see no reason to keep that restriction. As you said, I've made hundreds of extra edits when the changes could have been made in a single submission. I say go for it, until a situation arises that might cause us to reconsider the change. At the moment, I can't think of any that would. I would ask that moderators be extra cautious about submissions changing container records until the final outcome has been determined. Mhhutchins|talk 20:29, 1 February 2016 (UTC)

I think I remember it now. What we were concerned about in September 2009 was that some new editors were replacing the reference/container title when adding individual stories to collections/anthologies. I guess it's still a potential issue, but even if a flawed submission gets past the approving moderator, the mismatch should be caught by one of our nightly cleanup reports. Ahasuerus 00:20, 2 February 2016 (UTC)

Yep, that's why we did it. Perhaps we can have a warning for both submitter and moderator that the container title record has been edited? Mhhutchins|talk 01:20, 2 February 2016 (UTC)

It would be non-trivial to add a warning for submitters, but I think a moderator warning should be doable. I'll take a look... Ahasuerus 05:05, 2 February 2016 (UTC)

Linking to Locus1 and FictionMags

I recall a while ago that someone was able to create stable links to listings on Locus1 and FictionMags. Does anyone remember how that is done? Thanks. Mhhutchins|talk 17:51, 5 February 2016 (UTC)

You seem to be looking for this discussion: ISFDB:Community Portal/Archive/Archive35#Linking to FictionMags. Uzume 16:18, 8 February 2016 (UTC)

Thanks for finding that discussion (heaven knows how hard it is to find anything in this wiki!). As I understand it, you still can't actually link to the Locus1 or FictionMags listing, only to the index to that listing. Still not exactly what we need, but closer than nothing. Thanks again. Mhhutchins|talk 17:22, 8 February 2016 (UTC)

Best way to enter novels broken across publications

I have a question on the best way to enter novels that are broken into multiple publications. This format is especially common for Japanese publications where a single novel is serialized across publications (sort of like chapbooks). I ask because I was looking at entering the Japanese translations of works by Diana Gabaldon (for starters) and I see several that are broken up like this. For example, the first I noticed is a translation of Dragonfly in Amber as "ジェイミーの墓標" (meaning: Jamie's gravestone) in three books:

JPNO 20534034: ジェイミーの墓標 1
JPNO 20540156: ジェイミーの墓標 2
JPNO 20550120: ジェイミーの墓標 3

I know some previous suggestions were to make title series for them but that does not represent the translations using our current variant methodology well and also these series are more like pub series that represent a single title as there is little to no guarantee that a novel broken in a certain way will be reprinted in the same format. This is why I sort of want to use our serial titles to represent such but what sort of publication should this be in and how to I enter this? Also if I use serial titles typically we variant these to the complete work but if the serials are also translations that is slightly problematic as we so not support multiple levels of variants. At a glance, I see at least six more translations of her novels published serialized in this format type (3 pubs representing Outlander, 3 pubs representing Voyager, 3 pubs representing Drums of Autumn, 4 pubs representing The Fiery Cross, 4 pubs representing A Breath of Snow and Ashes, 3 pubs representing An Echo in the Bone, etc.) and I know this is extremely common in Japanese publishing in general (even for native language content). I would like to know the recommended method before I enter hundreds of publications and we change our methodology. Thank you. Uzume 17:59, 8 February 2016 (UTC)

I can only suggest that you create separate publication records for each book, then variant them to the original title record representing the whole work. That's how some editors handles splits in other languages (like this one.) And there's precedent, since serials are varianted to the original title records. Aren't "splits" similar to a serial in form without appearing in a periodical, but in a separate book publication? Unfortunately, that method isn't consistent (see these two series: here and here). The only documentation I could find was here. but I'm not sure that method has ever actually been discussed among the community (or I don't remember ever seeing it.) It just doesn't feel right to me, since there's no connection between the records, other than placing them in the same series. But doing it that way means any user of the database would never know that, for example, The Reality Dysfunction by Hamilton, ever appeared in mass-market paperback in the US, but the split Portuguese paperbacks are right there under the original title record for the Hamilton novel, and the French splits are visible under the Cherryh novel's title record. That's why I personally prefer the variant method instead of the series method.

Of course, this problem would be solved if we had a relationship function...but I've harped on that forever and I've given up on ever seeing it happen. Mhhutchins|talk 20:15, 8 February 2016 (UTC)

I agree and that is why I brought the discussion here before I start entering piles of pubs and titles in some format only for us to to later decide a different methodology is more appropriate. It should be noted that we currently do not support native script in author records and publisher records which means all of these will have to be revisited anyway to put the original citations in when allowed. Uzume 21:33, 8 February 2016 (UTC)

I am in the process of adding "transliterated values" fields to our records. "Transliterated legal name(s)" was implemented in 2015. "Transliterated publication series name(s)" was added in January 2016. "Transliterated publisher names(s)" has been coded and will be added in the next day or two once I finish testing the changes. Series, publications, titles and authors' canonical names will be done in the coming weeks. They will all come with associated cleanup reports which will help identify records that haven't been properly transliterated yet. Ahasuerus 23:10, 8 February 2016 (UTC)

Well the point I am making is that transliterated names are basically a form or alternative name so we could potentially support things like variant author names and work titles using something akin to that. Uzume 01:50, 9 February 2016 (UTC)

I am afraid I am not seeing the similarity. Our pseudonyms and variant titles are created based on:

what's stated in publications
our knowledge of who wrote what
our knowledge of which texts are identical (or close to identical)

Transliterated names, on the other hand, are based on different transliteration systems. The reason that we support multiple transliterated values per field is that there is no single universally accepted system. Ahasuerus 22:42, 9 February 2016 (UTC)

I noticed how transliterated legal name and transliterated publication series was added to advanced search (I would really like to add OpenURL searching to ISFDB; there is no reason for any of our searching to use POST forms when GET forms would be fine and can be linked to easier). It sees to me this should generally be implicit when searching (unless someone really wants to target just such). We do not have separate ISBN-10 and ISBN-13 searches (of course not)? Uzume 01:50, 9 February 2016 (UTC)

Regular search already handles transliterated values seamlessly, just like you suggested. I tried to use the same approach with Advanced Search, but it killed performance, so I ended up implementing the current system. Advanced Search is due for an overhaul anyway, at which point I hope to address this issue. Ahasuerus 22:46, 9 February 2016 (UTC)

Cool! Maybe we can implement a standard search methodology like OpenURL too then. Uzume 22:28, 10 February 2016 (UTC)

By the way, I am curious about native script pubs and titles. Currently I believe we support such but is it alright to enter native script Japanese magazines? I have bibliographies for many "in genre" magazines and anthologies too (but I do not believe our new magazine directory supports anything but Latin script; http://homepage2.nifty.com/te2/b/home.htm seems to be sort of the Galactic Central of Japanese material—only that site does not seem to have covers). Uzume 21:33, 8 February 2016 (UTC)

I am curious what you mean by a relationship function. Do you mean a field to specify what type of "variant" a title is (I can see the usefulness of such but also the potential issues with such too)? Or did you have something else in mind? Uzume 21:33, 8 February 2016 (UTC)

The issue of "relationships" has been discussed a number of times, but it covers a multitude of sins, as it were. Here is what I wrote on this subject when it was last raised:

It looks like we have two separate although in part overlapping issues here. The first one is adding the ability to associate "people with roles other than author/anthology editor" with title records. The list of these "roles" is long and includes translators, editors of single author books, cover designers, adapters, etc. The biggest challenge here is the ability to support co-translators/co-editors/etc as well as pseudonyms, including collective pseudonyms. Over the last couple of months I have come up with a possible approach, which will hopefully work for translators and should be extendable to other "roles". There may also be a related issue of supporting "roles" for people associated with publication records, but I haven't given it much thought yet and it may be overkill anyway.
The second issue has to do with linking related titles. The first question that we face here is whether we want to support "one-to-many" title relationships or whether we want to limit this functionality to "one-to-one" relationships. "One-to-one" relationships are fairly straightforward and include abridgements, adaptations (plays etc), expansions, revisions and so on. "One-to-many" relationships are more complex and include things like fix-ups where a single novel may be linked to multiple short stories.
Once we decide what types of relationships we want to support, we will need to make other decisions. For example, do we allow arbitrary relationships or do we limit them to a predefined set ("abridgement", "expansion", "adaptation", "revision", etc) which would be displayed to editors as a drop-down list? Also, what should we do about titles that have multiple relationships, e.g. "revised abridged" texts? Should we have a separate relationship for each permutation (which would make the list long and unwieldy) or should we allow multiple concurrent relationships between titles so that we could have "revised" and "abridged" specified separately? BTW, this is one reason why translations are somewhat different: you can have abridged or adapted translations, e.g. Alexander Volkov's adaptations of the Oz books or Brian Stableford's adaptations of numerous French novels.
Finally, how do we want to display related titles on Summary pages? Should we display them as independent entities with "[abridgement of Wizard of Oz by Joe Q. Author]" or "[fixup of X and Y"] next to them? Or should we display them together, similar to the way we display variant titles? It would seem that certain types of relationships like minor revisions/abridgements/expansions would look better if we could display them together. On the other hand, would it still work for significant alterations like 30 page abridgements of novels?
I should also add that we really ought to rewrite the database filing logic before we can implement whatever enhancements we agree on. Currently the approval logic for every submission type files data in its own way, which makes it hard to add new fields and especially non-trivial relationships. We need to centralize the filing logic so that there would be one place where title records would be filed, one place where publication records would be filed, etc. That's a fairly major change. Ahasuerus 18:36, 9 February 2015 (UTC)

P.S. We also have a related FR, "Contributor roles". Ahasuerus 23:13, 8 February 2016 (UTC)

OK, as interesting as those points are I am mostly interested in translator role. Uzume 01:41, 9 February 2016 (UTC)

I agree that adding translator support is more important than adding support for, say, "adapters". However, it's prudent to investigate whether it's possible to come up with a design that could handle all of these "roles" out of the gate. It may help avoid all kinds of design unpleasantness down the road. Ahasuerus 22:32, 9 February 2016 (UTC)

Agreed. But some types of attribution are inherently different. Some are based on collections of works (a novel with some pictures, etc.) and others on derivatives (which should always credit the original). Perhaps we can focus on the two different types and design general methods for handling such and then implement and test it. Uzume 22:28, 10 February 2016 (UTC)

Any "co" roles in my mind can just be listed with the main ones (I see little value in supporting "co-author" when one can just have more than one author). Uzume 01:41, 9 February 2016 (UTC)

I am not 100% sure that I fully understand this comment. The challenge with supporting multiple/pseudonymous translators is coming up with a table layout that would support all possible permutations. Our original attempt to address translators (see "title_translator" in the "titles" table) was a failure because we didn't account for that. Ahasuerus 22:32, 9 February 2016 (UTC)

I am not sure I understand either. In my mind, translations, like reviews, are by definition derivative works so why can they not be handled in a similar way? There is an original title X. It has a cover art title Y, interior art title Z and potential review titles A1, A2, A3 as well as potential translation titles B1, B2, B3, etc. With a little thought it seems possible, though using the current title variant mechanism might not be optimal. Maybe my view is too simplistic? Uzume 22:28, 10 February 2016 (UTC)

As for for the work relationships, I believe translations are important, as those works in general do not stand on their own. As for abridgments, etc. methinks it would be fine to handle them more like review links (let them be listed separately and perhaps we can add a link to a related work and just state the relationship). Of course others will have other opinions but that is my take on it. Uzume 01:41, 9 February 2016 (UTC)

You can also do something similar to this series. In English, the publisher took two of the Japanese volumes and merged them into one volume. ···日本穣 · 投稿 · Talk to Nihonjoe 23:47, 8 February 2016 (UTC)

That is an interesting data point, however, I am not sure it is entirely applicable as those volumes that were merged were listed in the original Japanese and being "上" (upper; used for first part) and "下" (lower; used for last part). That said, the use of an "omnibus" seems questionable under this situation as obviously the original printings were listed as splits and not complete works/novels to begin with (I think I would have varianted them to an unsplit titles instead; that way when unsplit or different split pubs arrive things do not get too ugly). Notice how different The Twelve Kingdoms looks from The Twelve Kingdoms (that break down is also listed on the Japanese Wikipedia as well). Uzume 01:12, 9 February 2016 (UTC)

The question remains can/should I enter these like:

ディファレンス・エンジン〈上〉 and ディファレンス・エンジン〈下〉 (I like this precedent as in my opinion the pubs really are chapbooks and the splits make sense as serials as they do not really stand alone despite having been published that way; I wonder if there is a cleanup report against putting serial titles in chapbook pubs though or the like)
2312 太陽系動乱 (上) and 2312 太陽系動乱 (下) (this is not a bad precedent either and adheres to ISFDB:FAQ#How does the ISFDB deal with "split novels"?)
a subseries that is just broken up a different way (I really do not like this one as it makes it hard to see the relationships between the split titles and nonsplit titles, etc.; in my opinion this is especially bad for translations and one never knows when or what might get popular enough to get translated)
something else

And finally, I know this maybe somewhat subjective but how does one determine when to use this sort of split technique vs. just dropping them into a series (are 1, 2, 3 split identifiers or series identifiers, etc.)? Any guidance is appreciated.

If I use chapbook, that generates an extra container title (irrespective if I use novel or serial for the contained title), so I could actually do both by putting the chapbook container titles into a subseries while also variant'ing the contained titles. Uzume 00:10, 10 February 2016 (UTC)

There are software safeguards against putting CHAPBOOKs in series. It's possible to get around them, but there is a cleanup report to find offenders. On the other hand, there are no provisions against putting SERIALs into CHAPBOOKs, e.g. see the Dark Kings series by Donna Grant. Ahasuerus 15:47, 10 February 2016 (UTC)

Really? Why is that? They are containers and there are collections and anthologies, etc. in series. Uzume 22:28, 10 February 2016 (UTC)

There are some borderline cases where CHAPBOOK series may make sense. However, in 99%+ of all cases it's the contained SHORTFICTION/POEM title that the submitting editor wants to add to a series. This was a fairly big problem for many years, so we ended up adding this limitation on the software side. Ahasuerus 23:02, 10 February 2016 (UTC)

I agree that putting the contained content into series is often the more important concept but I do not understand how such could be a big problem. Are we running out of space for submissions or just moderators to moderate them (all such submission are still moderated are they not?)? Uzume 23:28, 10 February 2016 (UTC)

Neither, really. The ability to add CHAPBOOKs to series was something that used to trip up many editors, including moderators. Disentangling the resulting messes was a constant headache, hence the implementation of this safeguard. Ahasuerus 00:24, 11 February 2016 (UTC)

It seems to me, moderation warnings and perhaps editor warnings would be sufficient. Uzume 01:36, 11 February 2016 (UTC)

I really think something like Night's Dawn Trilogy (paperback) (is it really a trilogy in six parts? also the other translations in the parent series are split but variant'ed) and 十二国記 / The Twelve Kingdoms (those are not really separate novels and as such I do not understand how the combined pubs are really omnibuses) are wrong because the relationships are broken (and frankly I would like to clean them up). Thank you. Uzume 00:10, 10 February 2016 (UTC)

Because the original Japanese publications were split into two separate novels labeled 上 and 下. Therefore, when the English version was released and combined them into one volume, it was an omnibus, combining the two novels into one. At the time, I discussed it with Ahasuerus and that is what we determined. ···日本穣 · 投稿 · Talk to Nihonjoe 16:59, 10 February 2016 (UTC)

I am not sure I agree with such a choice (often later Japanese pubs will either not split them or split them differently) but such is life (it is hard to see into the future). Uzume 22:28, 10 February 2016 (UTC)

Server downtime - 2016-02-09

The server will be unavailable between 6pm and 6:05pm server (Eastern-US Standard) time. The patch will add support for transliterated publisher names. Patch notes should be posted by 6:30pm. Ahasuerus 22:10, 9 February 2016 (UTC)

The server is back up. Ahasuerus 23:06, 9 February 2016 (UTC)

"Transliterated publisher names" are now live. They work similarly to the way transliterated publication series names work with the following caveats:

"Publisher Directory" has been updated to support transliterated publisher names. For example, the "zn" page lists Знание because its transliterated name is "Znanie".
Publisher Merge (moderator-only) has been updated.
Edit Publisher has been changed to enforce publisher name uniqueness.

A new moderator-only cleanup report will become available around 1:30am server time.

As always, if you find encounter issues, please post them here. Help will be updated shortly. Ahasuerus 23:18, 9 February 2016 (UTC)

How does this handle (if at all) variant publisher names (based on just transliteration differences). For example, Kurodanhan Press published both Japanese and English texts and I am sure the publications published by them have the publisher listed differently based on the language of the publication ("黒田藩プレス" in Japanese pubs and "Kurodanhan Press" in English publications). Or do we just have to handle them as if they are different imprints (even though they both mean exactly the same thing). Thanks. Uzume 01:30, 10 February 2016 (UTC)

Unlike titles, publishers do not support "variants" at this time. I suggest we raise this issue on the Rules and Standards page. Ahasuerus 15:42, 10 February 2016 (UTC)

OK. Uzume 22:36, 10 February 2016 (UTC)

Also how do I submit publisher name changes like renaming Asahi Sonorama to 朝日ソノラマ (and of course adding Asahi Sonorama as a transliteration)? I managed to make submission 2946481 but I had to use a convoluted method to enter it. Uzume 13:57, 10 February 2016 (UTC)

As per Help:Screen:EditPublisher, "only moderators can edit [Publisher Name] once the publisher record has been created". The reason this limitation was implemented was to prevent well-meaning editors from creating submissions to change established publisher names like Macmillan.

There is a new moderator-only cleanup report that finds Latin/non-Latin mismatches between publishers and titles. At this time it lists 270 publishers. I will be working on it starting today and expect the list to shrink in the coming days. Once I take care of the usual suspects, I am sure I will need help with a number of more obscure Japaneses, Arabic, etc publishers. Ahasuerus 15:39, 10 February 2016 (UTC)

That seems like an odd choice since the submission should be moderated anyway, it should regardless go through a moderator. And it makes it so editors like myself cannot easily help with such unless it is brought to a public forum in the way are you are proposing (or one takes convoluted means to make such submissions as I demonstrated; which by the way was approved). To me it is not unlike changing a canonical name. Obviously, if I made a submission to change "Piers Anthony" to something else I would hope it would be stopped in the same way as a submission to change "Macmillan" would be. Uzume 22:36, 10 February 2016 (UTC)

At one point a few well-meaning-but-misguided submissions got through and messed up a couple of major publishers. This limitation was added as an additional safeguard once the mess had been cleaned up. Ahasuerus 22:48, 10 February 2016 (UTC)

That sounds like a moderation issue—punishing the masses due to a limitation of a (otherwise incredibly hard working and amazing) few. Uzume 23:25, 10 February 2016 (UTC)

It's true that in an ideal world moderators would catch all questionable submissions. However, that doesn't always happen, especially late at night when moderators tend to be tired. That's why we have implemented additional safeguards to reduce the likelihood of significant damage to the database. To use another example, the ability to merge authors and publishers is not available to non-moderators for similar reasons. It may be worth considering making the ability to edit canonical names moderator-only as well. Ahasuerus 00:05, 11 February 2016 (UTC)

It still seems to me, editor and moderator warnings would be sufficient ("this change affects <large number> of records; perhaps get consensus before" "submitting this change" or "committing this submission", etc.). Uzume 01:43, 11 February 2016 (UTC)

Unfortunately, our (rather painful) experience was different :-( Ahasuerus 05:35, 11 February 2016 (UTC)

(status update) I have taken care of the low-hanging fruit (the Ancient Greek version of Harry Potter was fun!) and we are now down to 161 questionable publishers. I expect that I will be able to clean up another dozen or two, but then I will need help. I think it will make sense to make the report accessible by non-moderators sans the ability to "ignore" publishers -- I'll work on it next. Ahasuerus 22:48, 10 February 2016 (UTC)

I bet that was fun. Thank you again. Uzume 23:25, 10 February 2016 (UTC)

Sure thing! The cleanup report is now available to non-moderators -- please see the announcement below. Ahasuerus 00:05, 11 February 2016 (UTC)

Thanks (I noticed that Harry Potter edition is the only Ancient Greek publication record we have that has an ISBN—woot!). Uzume 00:10, 11 February 2016 (UTC)

Additional cleanup reports made available to non-moderators

The following cleanup reports have been made available to non-moderators:

Series with Numbering Gaps
Suspected Latin/Non-Latin Publication Series Name Issues
Suspected Latin/Non-Latin Publiher Name Issues

Ahasuerus 00:00, 11 February 2016 (UTC)

Report 99 needs minor cosmetic adjustment: "Publiher" Uzume 00:12, 11 February 2016 (UTC)

Fixed - thanks. Ahasuerus 00:20, 11 February 2016 (UTC)

Cover images at Project Gutenberg

Project Gutenberg is not listed at Help:Screen:NewPub#Image URL among "external sites which have given ISFDB explicit permission to link to them".

I wonder about this having visited its HTML release of My Father's Dragon, first edition P558873, where the lead paragraph begins "This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever."[2] And then visiting its cover image.[3] --Pwendt|talk 22:35, 13 February 2016 (UTC)

We don't just link to images, we "deep link". That means we draw bandwidth from the host's server in order to display their image on our webpage. Many websites, including PG, consider this bandwidth theft. If you're certain that the image is the correct one for the publication, download the file, resize it to ISFDB standards, and then upload it to our server, using the "Upload cover scan" link on the publication record. Then you can link it to the ISFDB publication record under the Fair Use provision of US copyright. Mhhutchins|talk 23:08, 13 February 2016 (UTC)

I am not certain about that particular title but likely the image can be copied not just under fair use but also under public domain as most works on PG as unlicensed as such. Uzume 17:08, 15 February 2016 (UTC)

Mouseover Help cleanup

Mouseover help has been cleaned up. It should no longer try to link back to the current ISFDB page if there is no Wiki page for it to link to. A number of other minor HTML corrections have been made -- if you run into any issues while editing records, please report them here. Ahasuerus 23:44, 13 February 2016 (UTC)

I wonder how well mouseover works for our text-based browsers users. Uzume 17:02, 15 February 2016 (UTC)

Greek translation of a Richard Blade story by "Jeffrey Lord"

Will the editor who created this record please variant it to the original English title? I'd do it myself but have no clue to what it could be. Mhhutchins|talk 06:58, 14 February 2016 (UTC)

The Greek SciFi Wiki lists it as Looters of Tharn (#37). I varianted the title record. --Willem 10:15, 14 February 2016 (UTC)

Advanced Search tweaks

Advanced Search has been tweaked to display authors' Working Language and not to display record numbers. Ahasuerus 01:17, 15 February 2016 (UTC)

Thanks!--Dirk P Broer 20:33, 15 February 2016 (UTC)

Since we are talking about pub series merges...

This is a different issue but at least technically related. I am interested in merging the pub series ハヤカワ・ファンタジー (Hayakawa Fantasy) with ハヤカワ・SF (Hayakawa SF series). The documentation I have on these (e.g., JA Wikipedia) claims Hayakawa Fantasy was renamed to Hayakawa SF series. There is something to be said about keeping records that cite what is printed on the publications, however, I believe there are also later reprints with the same number but the later name (unfortunately these are hard to discern as the publisher does not make the printing history very explicit). Anyway, since the last conversation was claiming they are the same pub series and keep them merged, I wondered if this also applied here (even though a number of pubs cite something different; I thought I would bring this up once I had the first series completely entered but since this topic came up perhaps better to field it along side for better interest and feedback). Thoughts? Thank you. Uzume 21:39, 15 February 2016 (UTC)

If the two publication series used two different names, then it's a different scenario vis a vis the one discussed earlier today. I think merging them would be counterproductive. Ahasuerus 01:13, 16 February 2016 (UTC)

I certainly considered and wondered about that myself. I assume any definitive reprints that used the new series name should go into the new series as labelled despite the interesting jump in dates and numbers. I did well label the change in the notes. Perhaps that is the best solution. Uzume 05:24, 16 February 2016 (UTC)

SF Collectors' Editions

The Note associated with SF Collectors' Editions currently reads:

A series of trade paperback reprints, all with bright yellow covers, no artwork, and with an encircling band of the Gollancz SF logo in various colors. [...]

However, if you follow the link, you will see that 17 of the pubs have artwork on the cover. Would anyone happen to know if the cover design was changed halfway through the run? Ahasuerus 01:10, 16 February 2016 (UTC)

I'm not sure exactly then it happened, but I recall some titles, like Floating Worlds and Tik-Tok, which were originally without art, being reprinted with cover art. I suggest removing the "no artwork" statement. Mhhutchins|talk 02:09, 16 February 2016 (UTC)

Done - thanks! Ahasuerus 02:39, 16 February 2016 (UTC)

"Gollancz SF" or "Ten Greatest SF Novels of All Time"?

I am in the process of moving the final publication series, Gollancz SF Series, to the database (not counting the 4 pub series which will continue to have Wiki pages.) Although our Wiki page calls it "Gollancz SF Series", some publication records refer to it as "Ten Greatest SF Novels of All Time", e.g. this edition of Ubik. Would anyone happen to know if the name of this publication series changed? Or did the publisher use the two names interchangeably? Ahasuerus 01:39, 16 February 2016 (UTC)

I'd go with the latter title for the series, but I don't have any of them to confirm that. BTW, which are the four series which will remain on the wiki? Mhhutchins|talk 02:14, 16 February 2016 (UTC)

They are listed under Category:Publication Series. Now that I have taken another look, I think it may be possible to move most, if not all of them to the database. Here are the reasons why I originally thought we should keep these Wiki pages:

Hamlyn's Venture SF - contains a scan showing the evolution of spine design. Perhaps we could link the Wiki-hosted image directly instead?
Bantam Spectra Special Editions - lists first editions, first paperback editions, first American editions and reprints. Move the list to the Note field as a simplified HTML table and add a "BREAK"?
Avon SF Rediscovery - little more than a collection of cover scans which can be easily seen within the database by clicking "Show covers". Can be deleted.
Series:Winston Science Fiction - selected covers and a few paragraphs worth of background information about this publication series. We can move the text to the database (after the obligatory "BREAK".) The covers are no longer an issue.

Ahasuerus 03:00, 16 February 2016 (UTC)

OK, everything has been moved to the database proper. Now to create cleanup reports to facilitate moving Series-, Publication- and Publisher-specific Wiki pages... Ahasuerus 23:16, 16 February 2016 (UTC)

I remember working rather arduously on the wiki page for the Avon series, but I understand it's better that it be in the database proper. The difference with the series as presented in the database is that the cover images and the data are on separate pages, but I guess it's the same number of clicks to get from one to the other as it was in the wiki. I also did the bulk of work on the Bantam Spectra Special Editions page, so I'm glad that you were able to transfer the data about the editions. Thanks. Mhhutchins|talk 07:00, 17 February 2016 (UTC)

Come to think of it, it may be beneficial to have a "composite" way of displaying publication series pages. I'll play with the layout to see what I can do. Ahasuerus 15:29, 17 February 2016 (UTC)

Yes, that would be an ideal way of presenting a publication series, since the cover design is what makes it into a publication from the start. Of course, one should have the option of seeing just the data without the covers. Mhhutchins|talk 20:47, 17 February 2016 (UTC)

Popular Library

Does anyone know if Popular Library, Inc., a publisher of sf periodicals from 1964-1971, is the same as Popular Library, publisher of paperback books from 1944 to 1991? If so, was the publisher designation intended to separate the book publications from the periodicals? Mhhutchins|talk 00:49, 16 February 2016 (UTC)

I suspect so. I looked at some of the early books we have listed by "Popular Library", including the 1948 "The Case of the Crumpled Knave". One listing for this book on Abebooks explicitly lists it as published by "Popular Library, Inc.". So that book, at least, indicates these two publishers are the same. If we looked through more "Popular Library" books, I suspect we would find a lot of them being from "Popular Library, Inc.". Chavey 02:36, 17 February 2016 (UTC)

It appears that whoever entered the periodicals made a point of distinguishing the publisher name with the sole intention of keeping the books separate from the magazines. If that's the case, I'd just as well leave it as is. Does anyone else have an opinion of whether these two publishers should be merged? Mhhutchins|talk 06:53, 17 February 2016 (UTC)

Barbara Michaels / Elizabeth Peters

Is the non-spec-fic work of this author eligible for the database? I personally don't believe she qualifies as "above the threshold" under any criteria: the majority of her output is not spec-fic, and she is not widely known as a spec-fic author. If that's the case, only her spec-fic work should be entered into the database. Her Wikipedia page states "she was best known for her mystery and suspense novels." It goes on to say that "Under the name Barbara Michaels, she wrote primarily gothic and supernatural thrillers.". Is there anyone who has read her work or has a differing opinion about the eligibility of her non-spec-fic output? I'm afraid that allowing her mysteries into the database opens the door for other mystery/suspense/romance/thriller authors to get the same treatment. Mhhutchins|talk 20:56, 17 February 2016 (UTC)

I am not familiar with her and her work, however, based on what I see I concur (I assume you want to rip out the large pile of non-genre entries). As a feature request perhaps, I believe we should have cleanup report for non-genre works that appear with author credits who do not make the bar for full entry (we have a database, how hard is it to maintain a "makes the bar" bit?). People can then lobby to have authors included (and probably would easily get that if say an author has more than X works entered where more than Y% are genre fiction; we allow nonfiction). Uzume 04:50, 18 February 2016 (UTC)

A "Non-genre author" field wouldn't be hard to add to author records. It wouldn't resolve the perennial "threshold" issue, but it would help us eliminate the low-hanging fruit, which is currently hard to find. Ahasuerus 05:39, 18 February 2016 (UTC)

I agree that (1) Barbara Michaels is a non-genre author; (2) All of her non-genre work should be excised from our records; (3) It would be a very helpful feature to have a "non-genre author" flag which resulted in non-genre books being banned. Anything that helps our editors (esp. beginner editors) to understand our inclusion rules would be a good thing. Suggestion: On the summary page, list it under author tags, and have it appear before any of the "regular" tags. (Not 'implemented* as a tag, since it should be moderated, but just listed there.) Chavey 07:51, 18 February 2016 (UTC)

As usual : author (IMHO) below threshold, delete all non spec-fic. Note that I've asked for something along the lines of "I believe we should have cleanup report for non-genre works that appear with author credits who do not make the bar for full entry" but to no avail. Hauck 14:26, 18 February 2016 (UTC)

Is there a way for the database to determine if they meet this "bar for full entry"? If so, we should document it somewhere so we can use that same bar in making a determination of whether something should be included. ···日本穣 · 投稿 · Talk to Nihonjoe 17:03, 18 February 2016 (UTC)

Some authors are obviously not above the threshold where all of their work is eligible for the database. But there are some authors in that grey area that will need to be discussed. I can't imagine a day when the software will be able to make these decisions automatically. I like Hauck's suggestion that there be a cleanup script to list potential candidates, but still allow humans to make the final decision. Mhhutchins|talk 17:42, 18 February 2016 (UTC)

In fact the wording is Uzume's. IIRC I did ask for a clean-up report that found titles that were marked "non-genre" AND not PVed. I wished to target all those interminable series of Harlequin romances that were likely automatically inserted and savagely delete them. Hauck 18:18, 18 February 2016 (UTC)

OK, FR 860 has been created. Implementing it will be a two-step process. First we will need to add a new "genre/non-genre" field to Author records. It's not hard, just somewhat time-consuming because we will have to account for the new field during author merges and such. The second step will be the creation of a new cleanup report to find authors who are not marked as "genre" and have non-genre works. Once everything is in place, we should be able to start working on cleaning up the database (savagery optional!) As of last week, we had 1,173 authors with 4,836 non-genre titles. Ahasuerus 18:24, 18 February 2016 (UTC)

Nice, like this one? I also like these two publications Hauck 18:27, 18 February 2016 (UTC)

Well, the FR codifies the proposed functionality, but it doesn't specify where the elusive "threshold" lies. That said, the original intent of the Rules of Acquisition was not to exclude non-genre works by less prominent genre authors. It was to exclude non-genre works by "primarily non-genre" authors. As the Policy page says:

The goal here is to avoid cataloging everything ever published by James Fenimore Cooper, Robert Louis Stevenson, Honoré de Balzac and other popular authors. Instead, we want to catalog their speculative fiction works only.

Based on that, I am in favor of keeping non-genre works by all authors, no matter how minor, who have been mostly active in SF. Take JC Andrijeski whom you linked above. She has published about 30 SF works, 24 of them novels. She has also published a non-genre novel and a non-genre novella. That's a 15:1 ratio, which clearly makes her a "primarily SF" author. Keeping her non-genre works in the database helps those who are interested in her oeuvre by telling them that "no, this is not SF". For example, the title of the juvenile novel "Jack Dervish, Super Spy" makes it sound like it could be SF, but it turns out that it isn't. That's useful information and IMO very much worth preserving. Ahasuerus 18:52, 18 February 2016 (UTC)

I agree. Andrijeski's non-genre work should be documented in the database, and appropriately flagged. She qualifies as "above the threshold" because she the majority of her output is spec-fic. Michaels is widely considered a mystery writer, so only her spec-fic should be documented. Any enterprising ISFDB editor with time on their hands can create a bibliographic comments page and list all of Michaels' mysteries, but that would be unnecessary because we link to her Wikipedia page which already does that. Mhhutchins|talk 20:20, 18 February 2016 (UTC)

"Publisher Year" changes

The way publications are displayed on "Publisher Year" pages has been changed. The new layout is similar to the layout used on the Title page, e.g. see "Publisher Ace Books: Books Published in 1980". I plan to make similar changes to all "Diff Publications" and Publication Series pages shortly. Ahasuerus 22:05, 17 February 2016 (UTC)

"Diff Publications" done. Ahasuerus 23:19, 17 February 2016 (UTC)

Publication series done. A few columns have been tweaked, e.g. the "Date" column now shows the publication month. I plan to make similar changes to the regular ISBN search and to the publication-specific version of Advanced Search tomorrow. Ahasuerus 01:29, 18 February 2016 (UTC)

Regular ISBN search done. Ahasuerus 03:49, 18 February 2016 (UTC)

Very nice! Chavey 07:52, 18 February 2016 (UTC)

Yes, Sir! Looks great! Stonecreek 08:05, 18 February 2016 (UTC)

(unindent) Advanced Search done. Ahasuerus 20:57, 24 February 2016 (UTC)

Correct way to enter a NONFICTION which contains an ESSAY with the same title as the NONFICTION?

This NONFICTION book actually contains three titles: a preface ("Vorwort"), an introduction ("Einführung") and a translation of the ESSAY Supernatural Horror in Literature titled "Das übernatürliche Grauen in der Literatur". Until yesterday only the preface and introduction titles existed for this record in the database and I made a submission which should add the ESSAY "Das übernatürliche Grauen in der Literatur" in order to make all three titles of the book visible. My submission got rejected by Bluesman who instead changed the TYPE of the title record from NONFICTION to ESSAY. As a result, the publication finally displayed all three titles it contains, but it lost its "Title reference". Now after some more submissions by Hervé the publication record is back to its initial state.

I'm a bit confused now by all this. I'd expect the title and pub records to look like this (all correct as of now except for the bold part):

TITLE record with TYPE "NONFICTION" titled "Das übernatürliche Grauen in der Literatur"

PUBLICATION record with TYPE "NONFICTION" titled "Das übernatürliche Grauen in der Literatur" containing these three titles (page number, title, type, parent):

6, Vorbemerkung (Das übernatürliche Grauen in der Literatur), ESSAY
9, Einleitung (Das übernatürliche Grauen in der Literatur), ESSAY, trans. of Introduction (The Annotated Supernatural Horror in Literature) 2000)
33, Das übernatürliche Grauen in der Literatur, ESSAY, trans. of Supernatural Horror in Literature 1927)

What's the correct way to handle this?

Jens Hitspacebar 17:39, 18 February 2016 (UTC)

As long as the content is typed as ESSAY, it doesn't matter if it has the same title as the book itself. There's only a conflict if it has the same title and the same type. I just updated the record by adding an ESSAY content record titled "Das übernatürliche Grauen in der Literatur". Then I varianted that new title record to the original English title record. I'm not sure why the original type had to be changed in the first place. Perhaps because it was so long in the German translation that the moderator believed it was a book-length work (usually typed as NONFICTION), and so there shouldn't be a content record for it. That's how it is normally handled. It is strange that it took 200 pages to translate a work that averages about 60-75 pages in English, but that's how translations work sometimes. Mhhutchins|talk 18:04, 18 February 2016 (UTC)

Ok, thanks, looks good now. The submission you did looks the same as my rejected submission, so my submission was correct actually. Good to know, now I'm back in "unconfused" mode :) As for the 200 pages: the essay is full of footnotes by S. T. Joshi, which blows ups Lovecraft's text (the English original "The Annotated Supernatural Horror in Literature: Revised and Enlarged", which this German version is based on, has a similar page count of 228). Jens Hitspacebar 18:38, 18 February 2016 (UTC)

Now that makes sense! I would suggest adding a content record, typed as ESSAY of course, for "Annotations (Das übernatürliche Grauen in der Literatur)" credited to Joshi. But that's up to you. Then you could variant it to this record. Mhhutchins|talk 18:48, 18 February 2016 (UTC)

Good idea! Done. Jens Hitspacebar 23:09, 18 February 2016 (UTC)

Changes to searches

Regular and ISFDB searches have been changed to submit search parameters in their respective URLs. This means that you can link or bookmark your search results. In addition, you no longer need to resubmit the form when refreshing Web pages with search results.

Please note that URLs are limited to 2,083 characters. It shouldn't be an issue in most cases, but the way Unicode characters are represented in URLs, they take an awful lot of room. Advanced Searches that use long Unicode strings may be affected by this limitation. Ahasuerus 21:59, 18 February 2016 (UTC)

Weekend support (19-22)

It looks like I will have limited internet access until Monday night. If anything major comes up, please e-mail User:Alvonruff. Ahasuerus 23:53, 18 February 2016 (UTC)

Back in business. Ahasuerus 01:11, 22 February 2016 (UTC)

New How-To which explains how to get around the "Error creating thumbnail" error

I just created a new How-To to explain how to get around the "Error creating thumbnail" message: How to get the image displayed on its wiki page. What do you think, is it ok this way? Feel free to improve it :) If there's no objection I'd add links to this page on the How to upload images to the ISFDB wiki and How to pages. Jens Hitspacebar 21:09, 20 February 2016 (UTC)

Great idea. This provides us a page to direct editors who are having this problem. I've done some simplification and clarification to your original instructions, and then linked the page to the "How To" list. Thanks. Mhhutchins|talk 18:49, 22 February 2016 (UTC)

Help documentation for converting a NOVEL to a CHAPBOOK

I have rewritten the instructions for conversion because the original instructions weren't clear in how to deal with the two different situations in these cases. Mhhutchins|talk 18:26, 22 February 2016 (UTC)

2016-02-22 server outage (8pm)

The server will be down for maintenance between 8pm and 8:05pm server (Eastern Standard) time. Ahasuerus 00:25, 23 February 2016 (UTC)

Everything should be back up. Advanced Search has been tweaked internally, but there should be few user-experienced changes. The most obvious one is that the "Next Page" link at the bottom of Advanced Search pages has been changed to a button. Ahasuerus 01:06, 23 February 2016 (UTC)

And you changed the search forms to use GET over POST—thank you! Uzume 01:59, 23 February 2016 (UTC)

Oh, that was done 4 days ago :) Ahasuerus 02:13, 23 February 2016 (UTC)

It would have been nice to get the new table results layouts too (I am not sure about the Next button or the colors but I really like the verified column in the simple search results; looking forward to it being deployed on advanced search). Uzume 01:59, 23 February 2016 (UTC)

There are a couple of prerequisite patches that need to be deployed first, but I expect that the new results table will be available shortly. Ahasuerus 02:17, 23 February 2016 (UTC)

Yes, I would like to get a major overhaul on the searching (e.g., supporting something like OpenURL or the like) but these updates go a long ways towards helping with that. Being able to sort advanced title search results will be nice. I noticed I can do ISBN prefix searches from the simple search but that does not work from advanced. Uzume 02:39, 23 February 2016 (UTC)

2016-02-23 server outage (8pm)

The server will be down for maintenance between 8pm and 8:05pm server (Eastern Standard) time. The patch will further consolidate the Advanced Search software. The only user-experience difference will be better error processing when Author and Publication searches find no records to display. Ahasuerus 00:30, 24 February 2016 (UTC)

Everything should be back up. Ahasuerus 01:06, 24 February 2016 (UTC)

How great of you to keep everything up all the time. Thanks. Uzume 01:08, 24 February 2016 (UTC)

Thanks for the kind words, but I am just doing my part like everyone else :) Ahasuerus 01:41, 24 February 2016 (UTC)

I'm not sure if it were caused by this latest update, but the "Show All Titles" function isn't working. Mhhutchins|talk 04:05, 24 February 2016 (UTC)

The first patch was buggy and messed up "Show All Titles". I noticed the problem late at night and fixed it around 1am. Does it look OK now? Ahasuerus 21:19, 24 February 2016 (UTC)

Greek mystery — but probably not mystic.

Hello. I would be happy if anyone could identify the original title and author of the book advertised here.

It is credited to Wallace Moore, and supposed to belong to the Balzan of the Cat People series — but I have some doubts. The translated Greek title goes “Ofira (or Ophira), the Ice Queen" (or possibly "Queen of Glaciers"), which I haven't found anywhere. Could it be a quirky translation of Lights of Zetar, which I am not at all familiar with ? TIA for any enlightening piece of info. Linguist 20:53, 24 February 2016 (UTC).

I am not familiar with the series, but the back cover used on Lights of Zetar says:

A new world for Balzan to survive, where Orala the priestess plans to seduce him and Androth the Krell king to kill him.

"Ofira" is probably a mangling of "Orala". One could counter that "priestess" and "queen" are very different job descriptions, but this review provides an explanation:

“Orala the priestess” is not in this book. Never mentioned. I don’t know where that name or position came from. Yes, Balzan is the target of an attempted seduction, but it’s by a woman named Lenor, who is also the princess (not priestess) of the Krells and Androth’s daughter.

So the Greek title appears to be a hybrid between what's on the back cover of the English edition ("Orala") and what's actually in the book ("princess" = "queen"). Fun stuff! :) Ahasuerus 21:17, 24 February 2016 (UTC)

Thanks a lot for your research. I suppose this could be the explanation. What makes me hesitate, though, is the fact that the cover illustration is different, whereas it is Viper Fan's policy is to reproduce the original cover art, as is the case for the first two volumes of the series (see here and here). I tried to do an image research, but nothing came of it :o(. Linguist 21:52, 24 February 2016 (UTC).

Just found the rightful Greek translation of The Lights of Zetar : Τα φώτα του Ζετάρ (Ta fóta tou Zetár), 1980, Viper Fan #71. So I'm sorry about your ingenious explanation, but it can't be that ! As I had surmised earlier, the Greek credit to Moore and the mention of the Balzan series are just hogwash. Identifying the original cover would certainly help. Linguist 22:02, 24 February 2016 (UTC).

It was fun while it lasted! :) Ahasuerus 22:32, 24 February 2016 (UTC)

Advanced/Regular search - title searches

The way Advanced and regular search display title records has been standardized. Ahasuerus 01:21, 25 February 2016 (UTC)

Thanks, again. BTW, I noticed with the last update (not this one) you also changed the modularization of code (and thereby the URLs). I am all for getting rid of the unneeded intermediate pages we had before (one for the first bunch of search results and another for the subsequent), Uzume 01:39, 25 February 2016 (UTC)

There were a couple of reasons why Al had them set up differently back in 2005. There were issues with HTML form closing since you can't have a form within a form. There was also an issue with "Show All Titles", which linked directly to the "followup" page -- linking to the first page would have required styling a POST form as a URL, which is a pain. Once we switched from POST to GET, everything fell into place. Ahasuerus 03:06, 25 February 2016 (UTC)

however, I wonder if combining all the advanced searches together (title, author, and pub) is optimal Uzume 01:39, 25 February 2016 (UTC)

80-90% of the Advanced Search logic was already centralized in a class which resided in a separate module. The 3 CGI scripts merely parsed the search values and called class methods. The parsing algorithm was the same, so I folded the 3 scripts into 1 and added the class to the same module. I also moved the module to the "biblio" subdirectory, something that I had been planning to do for a very long time. Ahasuerus 03:06, 25 February 2016 (UTC)

(and if we do want that, it might make more sense to use PATH_INFO instead of the new TYPE parameter and then we could combine say search.cgi and adv_search_results.cgi). Uzume 01:39, 25 February 2016 (UTC)

The shared components of the two types of search have already been centralized or will be centralized shortly (authors.) The remaining components are rather different, but I will take another look once I finish the next round of changes. Ahasuerus 03:06, 25 February 2016 (UTC)

OK, great, but my points are more to combining search.cgi and adv_search_results.cgi (there can be one that either displays the forms or the results when the arguments are given). Also, I believe it would be good if we started using PATH_INFO more and a good first use would be to say make search.cgi return the form, search.cgi/titles?<form parameters> return the title search results, search.cgi/authors?<form parameters> the author search results, search.cgi/pubs?<form parameters> return pub search results, etc. It might also be possible to merge simple and advanced searching (making simple searching just use a different simplified form without as many options but call into the same results backend). Anyway, just some thoughts to discuss and mull over. Uzume 06:17, 25 February 2016 (UTC)

I am not sure I am seeing the value of these changes. Going forward, I suggest that we move technical discussions to the Development page since they are meaningless to the majority of our editors. Ahasuerus 16:15, 25 February 2016 (UTC)

Also I wanted to ask how are the column widths chosen with the new layout? For example, in advanced pub searches I find the "ISBN/Catalog#" column to be oversized and the "Publisher/Pub. Series" column undersized needlessly causing the rows to fold and double the vertical width. Similarly in advanced title searches the "Date" column seems undersized. Uzume 01:39, 25 February 2016 (UTC)

We can certainly review the spacing situation and make any necessary adjustments. It should be easier to do once the three Advanced Searches have been reconciled with their regular Search counterparts. Ahasuerus 03:06, 25 February 2016 (UTC)

I also wonder why we list title dates as YYYY-MM-DD and pub dates as MMM YYYY. Uzume 01:39, 25 February 2016 (UTC)

That's a good point. There is a similar issue on Title and Pub pages where dates are displayed inconsistently. My personal preference would be to use YYYY-MM-DD wherever possible instead of forcing our users to go to the next level to find the exact date. Ahasuerus 03:06, 25 February 2016 (UTC)

I also am a fan of the ISO 8601 style formats. To me, it just makes more sense to go from large to small (that way they auto sort themselves too) vs. the various national date formats (e.g., MM/DD/YYYY or DD MMM YYYY, etc.). Uzume 06:17, 25 February 2016 (UTC)

I think it would be best not to use technical terminology like "ISO 8601" on the Community Portal if there are other, more human-friendly, options available :) Ahasuerus 16:25, 25 February 2016 (UTC)

Advanced/Regular search - author searches

The way Advanced and regular search display author records has been standardized. The patch also fixed a nasty bug introduced in the previous patch. Ahasuerus 04:48, 25 February 2016 (UTC)

Advanced Search - paging

The way Advanced Search handles results with 101+ records has been corrected. All pages should display up to 100 records per page. The "Next Page" button has been changed to display correct values, i.e. "101-200", "201-300", etc. Ahasuerus 00:10, 26 February 2016 (UTC)

Pulp Magazine scans

The Internet Archive has scans of a large number of early magazines. For example, they scanned the entire run of If Magazine (I've added links to this page to the title series for that magazine.) I didn't see any other complete runs, but you can go to their Pulp Collection home page and do searches for magazines you're interested in. There are also a modest set of indexes, including Donald Day's "Index to the Science Fiction Magazines, 1926-1950" and a Weird Tales index. Chavey 06:55, 26 February 2016 (UTC)

Thank you for sharing that. It is quite interesting. It seems they also have others outside of the Pulp Collection like for example (it looks like) the entire Starlog magazine and Ares magazine (both are somewhat fringe for inclusion here but are probably of interested to people that do come here). Others that might be somewhat interesting include Game and Gamer Magazines, Comic Books and Graphic Novels, etc. Uzume 21:18, 26 February 2016 (UTC)

One can also find things like A Princess of Mars, Grosset & Dunlap, October 1917 (as part of The Science Fiction and Fantasy Fiction Collection) which makes me wonder about the publication date of our own record P286171 which says Grosset & Dunlap, 1918. Their scan has "Published October, 1917" on the copyright page. Uzume 21:38, 26 February 2016 (UTC)

Wikipedia states it was serialized in 1912 and published in hardcover in 1917. ···日本穣 · 投稿 · Talk to Nihonjoe 22:20, 26 February 2016 (UTC)

Our record points to the LCCN which states 1918 but then points to HathiTrust which also has two scans where the copyright page of each says October 1917 as well (one of the two scans, the one from University of California, is the same as the one at Internet Archive). Uzume 16:49, 27 February 2016 (UTC)

Here's a scan to the first serialized entry: [4]. ···日本穣 · 投稿 · Talk to Nihonjoe 00:07, 28 February 2016 (UTC)

Displaying "unpublished" titles

I would like to get other users' opinions of the recent change in how unpublished titles are displayed. I personally believe it's unnecessary to highlight such titles. The word "unpublished" sufficiently describes the title without having the blaring highlight to point out that fact.
Here's how it appears on a publication page.
Here's how it appears on an author's summary page.
Here's how it appears on a title page.
Here's how it appears on a series page.
Mhhutchins|talk 16:15, 26 February 2016 (UTC)

I'd also say that the longer and lettered "unpublished" suffices in directing any attention of editors towards the respective titles. Stonecreek 16:32, 26 February 2016 (UTC)

Ok with Michael. Hauck 16:35, 26 February 2016 (UTC)

Neither irked nor elated by it. Linguist 17:08, 26 February 2016 (UTC).

It's indeed a little bit too intrusive. Rudam 20:36, 26 February 2016 (UTC)

Agreed. I can live with the current scheme and I do not mind it being emphasized/highlighted in some way but it currently seems overly emphasized/garish (about the only way it could be worse would be to use blink but thankfully very few browsers even support that any more). Uzume 20:47, 26 February 2016 (UTC)

I think the green highlight should be removed completely, especially if there's no indication why it is highlighted. It draws too much attention to the "unpublished" label und distracts from the rest of the data visible on a page. As for the question if "unpublished" is self-explanatory: I can imagine that someone who only knows little or nothing about book publishing (gasp!) can misinterpret "unpublished" as "not published yet". No idea how likely this actually is, but if you put all your knowledge about the publishing process aside, the word "unpublished" only tells you that a book has not been published, but it doesn't give you a time context: is the "publishing process" over (it stays unpublished) or still going on. Imagine a kid: "Dad, what about 'Donald Duck vs. Batman' which was being advertised last year?" Dad: "It's unpublished". Kid: "Oh. So, when does it come out?". Therefore I think it's still a good idea to somehow explain "unpublished", preferably in a way that the user doesn't have to search for the explanation: a possibility is to add the question mark icon (the one used on the edit pages) next to the "unpublished" label and explain the meaning of "unpublished" in a mouseover hint. Jens Hitspacebar 20:57, 26 February 2016 (UTC)

(outdent) The current version is too much. I don't believe the highlighting helps. Either people understand our terminology or they don't. If they don't, adding mouse over text could help (don't see the need for the question mark icon though; that could add further confusion - "unpublished?"), but highlighting doesn't. -- JLaTondre (talk) 22:18, 26 February 2016 (UTC)

Interesting point. I haven't seen it that way yet. I'd expect that a question mark icon is commonly known to internet users as something to help you. An alternative, less obtrusive and less prone to misinterpretation than the icon, would be to instead turn the "unpublished" label itself into a link which would point to a wiki page explaining "unpublished". The "title" attribute of the link element could be something like "Publication was planned but never published. Click here for more information about "unpublished"". Jens Hitspacebar 16:09, 27 February 2016 (UTC)

It sounds like the consensus is that the current color-coding is unnecessary and should be replaced with some kind of mouse-over text and possibly a question mark icon. Let me do the low-hanging fruit first and then we can decide what to do with the icon. Ahasuerus 16:19, 27 February 2016 (UTC)

The change has been deployed. I used the same question mark that our edit forms use because you couldn't tell that there was mouse-over help available without it. How does it look? Ahasuerus 21:01, 27 February 2016 (UTC)

Very good. Thanks. Mhhutchins|talk 22:23, 27 February 2016 (UTC)

Yep, much better now. Thanks a lot for the change. Jens Hitspacebar 09:57, 28 February 2016 (UTC)

Advanced Search - wildcards for publication searches

Are wildcards still supported for publication searches? http://www.isfdb.org/cgi-bin/search.cgi says "Wildcard is *" but I'm not seeing any records when I used it for publication searches. I was looking to see how zero price records are being entered. Searches for 0 and $0 return results for those exact strings. Adding * to them results in "No records found". --Marc Kupper|talk 20:23, 28 February 2016 (UTC)

Wildcard searches on the ISFDB have never worked for me. But it may be because I can't exactly figure out how to enter them. (Obviously not the way I've always used them on other websites' searches.) Mhhutchins|talk 20:44, 28 February 2016 (UTC)

Here is what the Advanced Code inline documentation currently says:

Exact match on price - not very useful?
Exact match on page count - not very useful?

Similarly, year and month searches expect exact values. All other fields should support "*" as a wildcard character.

We also have a Feature request to "Standardize wildcards used in regular and Advanced Search". The description reads:

There is a discrepancy between the way [regular] Search and Advanced Search handle wildcards. With regular Search, if you enter "heinl%n" in the search box, the resulting list will include all of our "Heinlein" records. In Advanced Search, you need to enter "heinl*n" in order to get the same results. (The underscore character, "_", matches a single arbitrary character in both cases.) The Community Portal consensus is that we should let users use either "%" or "" as wildcards.

Ahasuerus 22:29, 28 February 2016 (UTC)

Thank you Ahasuerus. I knew about the */% business and had tried both but was not aware that the price and page count fields only supported exact matches. That may motivate me to reinstall the database to do some local searches. I already have MySQL on my regular desktop. --Marc Kupper|talk 10:30, 29 February 2016 (UTC)

Well, we can easily change the code to allow wildcards when processing these publication fields, but then a search on "page count = 36" will become a search on "page count contains 36", so it will also find "136", "365", etc. Perhaps we should limit the change to the price field? Ahasuerus 19:30, 29 February 2016 (UTC)

Rather than CONTAINS can you use LIKE or RLIKE? RLIKE on the price may have one startling aspect which is that a dot (.) matches any single character. Marc Kupper|talk 20:38, 29 February 2016 (UTC)

Internally the code uses LIKE, but I try not to use technical terms on the Community Portal since they are meaningless to most editors. Ahasuerus 20:51, 29 February 2016 (UTC)

I have not looked at the code but are you translating * to % and using LIKE for the other fields? --Marc Kupper|talk 20:38, 29 February 2016 (UTC)

Yes, that's exactly what the code is doing. Ahasuerus 20:51, 29 February 2016 (UTC)

That's fine then. Your use of a nice bold contains made me nervous as it sounded like you were also proposing an automatic prepending/appending of "%" to convert a search for "abc" to "%abd%" like you do with title and author searches. --Marc Kupper|talk 00:37, 1 March 2016 (UTC)

There may have been a misunderstanding. In my last comment I wasn't proposing anything, I was just clarifying how the Advanced Search software works when handling submitted queries. In most cases, it checks whether the entered string exists within each eligible field. When dealing with certain fields mentioned earlier -- price, page count, year, month, binding, title type -- the software expect an exact match. There is also special logic for ISBNs to account for hyphens and 10-vs-13 differences. There is FR 751 to allow partial matching on years and there is more general FR 219 to allow specifying "Complete" [exact], "Starts with", "Ends with", and "Anywhere" as search attributes. Ahasuerus 01:31, 1 March 2016 (UTC)

For the pub_price, pub_pages, and other small fields such as pub_isbn I believe we should have more control over the the query string submitted to the MySQL. In other words, replace:

clause = "pubs.pub_price='%s'" % (value) with

clause = "pubs.pub_price like '%s'" % (value)

A search for a price of "0" should result in "pub_price like '0'". If someone wants prices starting with 0 or ending with 0 then can use 0% or %0 respectively and would use \% to search for a % itself. There is a bit of weirdness in that you translate * into % but don't seem to have escape code to allow searching for *. I don't know what db.escape_string() does with \*. --Marc Kupper|talk 00:37, 1 March 2016 (UTC)

I think we would be better off implementing FR 219 to let users specify search attributes explicitly. Also, I suggest that we refrain from using technical terms on the Community Portal, at least as much as possible. They effectively prevent most of our editors from following the discussion. Ahasuerus 01:31, 1 March 2016 (UTC)

You made what looks exactly like a proposal for changes to searches of the 'page count' at 19:30, 29 February 2016. My answer to that is, no, I was not thinking of that and believe it's a bad idea to use "contains" as the default for those fields as usually people will be searching for very short strings. I then proposed an alternative that will allow the search to behave exactly as it does now (which is an exact match to what was searched for) while also giving end-users additional flexibility should they want to take advantage of it, and will allow the search to match the behavior that's documented on the advanced search page (with the * wildcard). My proposal does not prevent nor hinder also implementing FR 219.

My proposal conflicts with FR 751 in that with FR 751 someone wants to be able to type "195" in the year field and have it return all records from the 1950s. I'd respond to that with that they can type "195_" instead and it'll do exactly what they want and that's already available as an option for both the publication title and year fields and already works for both title and publication searches. The "_" is often called an underscore, understrike, underbar, or underline character. On many keyboards it shares a key with the hyphen-minus (-) on the top row, to the right of the 0 (zero) key. A "_" in a search matches any single character. A search for "a_c" will match letter "a" followed by any letter, digit, punctuation mark or space, that is then followed by the letter "c". It matches aac, abc, ... azc, a0c to a9c, a&c, etc. A search for 195_ might not have worked back in 2014-12-06 when FR 751 was requested but it's working today meaning all that's needed to mark FR 751 as resolved is to document the usage of _. 195_ also works for author birthdate and deathdate searches to list all births or deaths in that decade. You can use 195_-12 to discover author's born in a December in the 1950s. This link searches for author's born in "18__-" and died in "20__-" meaning they were born in the 1800s and died in the 21st century. --Marc Kupper|talk 03:11, 1 March 2016 (UTC)

Clean up report for price/currency field

I ran across a publication with "€ 14.99" which had an extra space. Template:PublicationFields:Price has "Do not enter a space when the currency is represented by a symbol (e.g. $, £, €, ¥)"

A suggested cleanup report is to locate and possibly fix inconsistent currency values. The patterns we should recognize include:

Empty/no price
None (not mentioned on Template:PublicationFields:Price but used on some records to indicate no price stated)
(0|0.00) (with no currency symbol)
$0 (apparently an undocumented standard for zero price)
[$£€¥][0-9]+\.[0-9][0-9]
[ACR]$[0-9]+\.[0-9][0-9]
(DM|Ft) [0-9]+\.[0-9][0-9]
(Lit) [0-9,]+
($£€) (one record with just € and over 100 with just $ or £ - I'm guessing this is an undocumented standard to note the currency and that the price is not known?)

The first pass will find many records that are valid and will need to be added to the list of rules above.

Possible fixups include:

L([0-9]+\.[0-9][0-9]) -> £\1
Y([0-9]+\.[0-9][0-9]) -> ¥\1
$C([0-9]+\.[0-9][0-9]) -> C$\1

--Marc Kupper|talk 20:33, 28 February 2016 (UTC)

If a universal change can be done with a script, that would be great. I think a cleanup report would be overwhelming except for those records which can't be fixed by a script. Mhhutchins|talk 20:46, 28 February 2016 (UTC)

OK, let's start small. I have coded and deployed a new cleanup report which looks for prices like:

¥ 662
£ 6.99
$ 7.99
C$ 17.95
$13,99
CDN$ 24.99
A$2,99

There are only 100 of them, so it should be doable. The data will become available in about 6 hours.

Once the low-hanging fruit has been taken care of, we can try to address the euro issue. There are some 1,600 pubs with a space after the euro sign and we will probably need a script for that. Ahasuerus 00:32, 29 February 2016 (UTC)

Thank you. I've dealt with the first pass. A number of the records were for the author Isuna Hasekura with the publications seeming to be graphic novels but it turned out those were what known as light novels in Japan and so are ok for ISFDB. The series is documented on Wikipedia at List of Spice and Wolf light novels. --Marc Kupper|talk 10:23, 29 February 2016 (UTC)

Yes, light novels have become quite popular lately. I have read a few. They are just regular, if somewhat simplified, novels. The biggest problem is that many of them are based on manga (and sometimes vice versa) and it can be difficult to distinguish between the two versions. I have found it useful to add the words "light novels" to series names in order to clarify things. Ahasuerus 17:24, 29 February 2016 (UTC)

If you ever have any where you aren't sure, let me know and I'll figure it out for you. It can be difficult sometimes. ···日本穣 · 投稿 · Talk to Nihonjoe 23:30, 2 March 2016 (UTC)

Thanks! Ahasuerus 23:58, 2 March 2016 (UTC)

Oops, I just noticed this series was very messed up (e.g., wrong publisher name for earlier parts of the series resulting in the "unclear" comment in the ASCII Media Works record note; the publisher should be メディアワークス aka "MediaWorks" which was merged with ASCII in 2008) and started a native script update on it (I made submissions for the first three already). In doing so I removed the words "light novels" from the series name (but added the native Japanese name instead). I did move the words "light novel" into the series note however. Uzume 01:00, 3 March 2016 (UTC)

If anyone cares, I completed the update of the series (including adding the missing English translations). I realized had I watched the corresponding anime series for this some time back and the story is cute and entertaining. Uzume 14:48, 4 March 2016 (UTC)

Hathitrust.org and handle.net

Hathitrust.org, or Hathi Trust Digital Library ,provides (perhaps among other things) books that google has digitized in color, page-by-page format that includes front and back covers, front and back endpapers --that is, apparently complete except dustjacket.

Do we use such editions for primary verification? Should we?

For publication records in the database I have consulted some of these editions that are linked from LC catalog records, and cited them in Notes, but not linked them. For example, Philip and the Faun, 1926 first edition P334199, currently the fourth list item under Notes. LC provides links to catalog.hathitrust.org; in this case [5]. That catalog in turn provides links to babel.hathitrust.org, where in this case two notes in the left margin give "Permanent link to this book" and "Link to this page" at hdl.handle.net. One instance of the latter in this case is the title page URL http://hdl.handle.net/2027/uc1.$b249485?urlappend=%3Bseq=7 --whose target shows the Atlantic Monthly Press colophon among other things.

Is it clear what targets we should welcome in links from publication Notes?

Comment: As I understand, Advanced Search for 'hathitrust.org' in Publication records Notes field returns a list of the publication records with 'hathitrust.org' in the Notes code, regardless whether that is displayed for the reader or hidden in a link. It is tricky to use Advanced Search in regard to this resource, however, because of great variety in the ways that this source might be cited --not only the URL targets mentioned above, but "Hathi Trust" as two-word proper noun, etc.

P.S. Advanced Search for 'hathitrust.org' (current search report) hits only one publication record with year more recent than my 1926 example P334199, namely a 1963 that I just now amended to say that the text is not available, limited search only P236721. Every other listing in the search report shows a year 1922 or earlier, when (pre 1923) books are routinely in the public domain. Why the 1926 exception? --Pwendt|talk 21:51, 28 February 2016 (UTC)

BTW, HathiTrust has more than just Google scans, e.g., http://catalog.hathitrust.org/Record/007652854 shows there are two scans: one from University of California and one from Harvard University. If you look at the Harvard University scan you can see it was created by Google. If you look at the University of California scan you can see it was created by Internet Archive and matches https://archive.org/details/princessofmars00burriala (though the two URLs display the content slightly differently the same handwritten marking "OC/1226637" can be seen on the dedication page of both; Internet Archive also identifies its scan as originating from University of California Libraries). Uzume 00:54, 2 March 2016 (UTC)

Reply to my P.S. hours later --searches of publication Notes for 'hathitrust.org', 'hathitrust', and 'hdl.handle.net' return close to 25, 75, and 100 hits. Years so recent as 1926 are a small minority but it is only in search for 'hathitrust.org' that that year seems to be anomaly. --Pwendt|talk 02:30, 29 February 2016 (UTC)

As I recall, we discussed the primary verification issue a while back. If I remember correctly, the consensus was that we shouldn't be using "primary" verification slots when verifying against online copies. Normally, the assumption is that the primary verifier(s) has access to the publication and can answer questions about it. Publicly available scanned books, on the other hand, can be taken down if the copyright situation changes, which has been known to happen. I guess "transient primary" verification may work in this case. Ahasuerus 18:03, 1 March 2016 (UTC)

If it is a facsimile scan then a transient primary verification against the printed original seems plausible. Of course, if we have an actual ebook record such a thing (similar to Gutenburg texts) then an online copy should probably be good for making a (non-transient) primary verification of such an ebook record too (it is not usual to be able to get useful data from other editions and printings). It seems to me all ebooks could go away unless everyone individually locally archives them somehow. Uzume 00:42, 2 March 2016 (UTC)

Changes to Edit Publication

As per FR 865, you can now edit "container" titles in Edit Publication. As long as they don't exist in other publications, of course.

There are two mechanisms preventing inexperienced editors from accidentally changing container titles to other title types. First, moderators will now see a warning if a container title is about to be changed to a different title type via EditPub. Second, there are cleanup reports which find publications without appropriate container titles, container titles with invalid 'storylen" values, etc. Ahasuerus 23:53, 1 March 2016 (UTC)

I've had an experience lately with an editor trying to "overwrite" an existing container record with entirely new data. That title happened to have an award attached to it. There was no warning that this shouldn't be allowed. If I hadn't noticed in the moderation of the submission that every field had been changed, I (or any other moderator) would have accidentally moved that award data to a new title. Does this change prevent that situation from happening? Mhhutchins|talk 18:31, 2 March 2016 (UTC)

Was that an Edit Title submission? If so, then this change would have made no difference since it only affected Edit Publication submissions. If, however, it was one of those rare Edit Pub situations that would let you edit container titles (prior to the last patch), e.g. if you had COLLECTION titles within an OMNIBUS publication, then yes, you would have seen a warning re: the proposed title type change if this patch had been installed at the time. Ahasuerus 19:29, 2 March 2016 (UTC)

No, it was an Edit Publication submission which edited a contained title record. The situation I described wouldn't have happened in an Edit Title submission, since it would have been obvious to the moderator that an editor shouldn't change every field of a title record, including the ENTRY TYPE field. Mhhutchins|talk 20:39, 2 March 2016 (UTC)

"Percent of Publications by Format by Year"

Percent of Publications by Format by Year has been updated to show ebooks. Ahasuerus 04:46, 2 March 2016 (UTC)

Wildcards in regular and Advanced searches

As per FR 790, wildcard behavior has been standardized. To quote the updated Advanced Search page:

Supported wildcards: * and % match any number of characters, _ matches one character

The new behavior is supported by all types of regular and advanced searches. In addition, the wording of the instructions that appear on the Advanced Search page has been streamlined. Ahasuerus 03:40, 4 March 2016 (UTC)

Thanks but I still cannot use advanced search to search for pubs via ISBN prefix, e.g. the first works and the second does not:

Any insights on why this is? Thank you. Uzume 05:19, 4 March 2016 (UTC)

It looks like it may be Bug 169 - Advanced ISBN Search doesn't find partial matches, although, as you noted in your 2011-03-04 comment on SourceForge, the current behavior can also be desirable under certain circumstances. Once we add the ability to specify whether the search value should be an "exact match", "contains", "starts with" or "ends with", we should be able to have it both ways. Ahasuerus 16:35, 4 March 2016 (UTC)

That is true but with wildcards one can specify all of those: "exact match"="XXX" (the default), "contains"="%XXX%", "starts with"="XXX%", "ends with"="%XXX", where "XXX"=target search value and "%" equals a wildcard (apparently either "%" or "*" now). The only tricky part with ISBN searches is any conversions we want to allow and or be user selectable. By conversions I mean the following types of things: a) I think stripping all characters except alphanumerics and converting to uppercase should be mandatory and does not need to be user-selectable (this way entries with hyphens or spaces, etc. will work correctly), b) we might want to have user-selectable control over ISBN10<->ISBN-13 conversions during an advanced search. Initially we should probably just turn that on effectively doing two searching and merging the results as simple search should do. Uzume 07:29, 6 March 2016 (UTC)

I suspect that the first step will be adding a new field for "catalog IDs" and migrating all non-ISBN values to it. After all, some books have both catalog IDs and ISBNs -- SFBC is a good example -- and we want to capture both data elements. Once the values in the current ISBN field have been limited to actual ISBNs, it will be easier to enforce additional restrictions. We may also need to add a field for "corrected ISBNs", but that would be step #2. Ahasuerus 02:41, 7 March 2016 (UTC)

I have no arguments there. It would be nice to support other identifiers and have cited ISBN vs. an "indexed" or synthetic ISBN (for fixing broken ISBNs and/or creating them from SBNs and/or partial ISBN catalog numbers as was done by some publishers for several years). I was mostly tryong to point out that there already exists ways to specify "exact match", "contains", "starts with" or "ends with" with our current wildcard system. I am assuming we implement such with SQL "LIKE" matching (thus the use of % and _ wildcards). Uzume 08:18, 7 March 2016 (UTC)

"Authors with Problematic Legal Names"

Non-moderators can now access the cleanup report "Authors with Problematic Legal Names". Ahasuerus 16:30, 4 March 2016 (UTC)

Advanced Title Search and tags

Advanced Title Search has been updated to support tag search. For example, you can find all titles published in 2010 with the world "juvenile" in one of the title's tags. The Web page that shows regular and Advanced Title search results has been adjusted to display each title's tags.

Caveat: As some of you know, there is a known issue with the way Advanced Search logic works when you specify multiple AND authors, e.g. "Niven AND Pournelle". The same issue will prevent you from specifying multiple AND tags, e.g. "juvenile AND young". I have added a warning to the main Advanced Search page. Ahasuerus 19:02, 4 March 2016 (UTC)

Wow, that's nevertheless great! I longed for this function, and now it's there! Stonecreek 07:40, 5 March 2016 (UTC)

Glad you liked it! :) Ahasuerus 15:20, 5 March 2016 (UTC)

Sorting Advanced Title Search results

Advanced Title Search has been modified to allow sorting results by title, year or title type. Ahasuerus 02:44, 6 March 2016 (UTC)

Cool, but methinks this broke the "Show All Titles" links. Uzume 07:20, 6 March 2016 (UTC)

"Show All Titles"

This function isn't working. Mhhutchins|talk 08:05, 6 March 2016 (UTC)

Sorry, it was an unintended side effect of the last Advanced Search change. Everything should be back to normal now. Ahasuerus 15:37, 6 March 2016 (UTC)

Sorting of numbered items in a series

On the author page for Yuichi Sasamoto, the items in the series are sorted as 1, 3, 4, 2 instead of in numerical order. Did something break? ···日本穣 · 投稿 · Talk to Nihonjoe 19:27, 6 March 2016 (UTC)

Nope. That's the way it's designed to work when a subseries is created. You can't order a subseries unless you make all of the other titles into their own subseries, numbering each. Mhhutchins|talk 19:51, 6 March 2016 (UTC)

Maybe we can get that fixed (feature request, perhaps?). The current way doesn't make sense if you are indicating a subseries is a specific number in the main series. ···日本穣 · 投稿 · Talk to Nihonjoe 19:58, 6 March 2016 (UTC)

Using sub-series numbers to insert a sub-series into a particular position within its parent series has never been supported, although I see that someone has been trying to use sub-series numbers that way.

Let me use Gotrek and Felix to illustrate why this approach can be problematic. See the two numbered sub-series at the bottom of the page? If we were to change the display logic to use their sub-series numbers to position them on the page, it would mess up the numbered entries in their parent series. I guess we could assign fake numbers like 101 and 102 to the sub-series, but then the unnumbered stories within the parent series would be separate from the numbered entries. Ahasuerus 21:40, 6 March 2016 (UTC)

So ordering titles within a series and ordering sub-series within a series are both supported but they are not ordered together into a single ordering (sub-series are at the bottom after titles). And unordered titles are after the ordered titles and similarly with sub-series (which are all after titles). That is good to know. Uzume 03:48, 9 March 2016 (UTC)

Advanced Title Search and "Non-genre"/"Graphic format"

"Non-genre" and "Graphic format" can now be used in Advanced Title Search. Ahasuerus 02:35, 7 March 2016 (UTC)

The Magazine of Fantasy & Science Fiction

isfdb stopped listing this magazine last year; the November/December 2015, January/February 2016, and March/April 2016 issues have not been listed. Why not? --Chris DeVito --Judas 03:30, 11 March 2016 (UTC)

Because none of our editors have done it. This is a voluntary community effort, and we depend on individuals like you to contribute when they see missing publications. Feel free to add records for those issues. Start with this page to learn how to create records. Thanks. Mhhutchins|talk 03:57, 11 March 2016 (UTC)

Summary bibliography: titles with non-latin characters / "forthcoming" infos

I just spotted two issues on Dmitry Glukhovsky's summary bibliography I'm not sure about whether they are intended this way or small software glitches:

1. This title is displayed correctly as "Метро 2033" on its title page, but strangely as "Mempo 2033" on the summary bibliography page (as for the latter: that's how it looks like on the summary bibliography, but I had to type it here using latin characters in order to mimic what is displayed because if I'd copy it from the summary bibliography page to the clipboard and paste it here, it'd strangely be pasted correctly as "Метро 2033"). Is anyone else seeing it as well or just my system?

2. It looks like the "[forthcoming: DATE]" information is only displayed for new titles only. If there's a title which has released pubs but als forthcoming ones (like this one), the "forthcoming" infos are not displayed. I think it'd be better and more consistent if it would be displayed as well in these cases. Bug?

Jens Hitspacebar 13:54, 12 March 2016 (UTC)

I can't address issue #1, but #2 isn't a bug. The ISFDB only displays titles on an author's summary page, not publications. So only new works will have the forthcoming tag. Since publications aren't displayed, they naturally wouldn't have a forthcoming tag. Mhhutchins|talk 17:02, 12 March 2016 (UTC)

Thanks for identifying the problem with Glukhovsky's Summary page! "m" is the cursive version of the Cyrillic "р", but I am not sure why the Summary page feels the need to convert the latter to the former. Let me dig some more... Ahasuerus 18:00, 12 March 2016 (UTC)

I just saw that the same thing happens on my My Recent Edits page in the "subject" column, where some submissions I did for Glukhovsky's pubs are currently listed. For example, it displays "Mempo 2035" as subject, whereas the record of the submission itself is displayed correctly as "Метро 2035".

Oh, wait, your link regarding italics explains it! I wasn't aware that the cursive version of some Cyrillic letters is different from the regular ones. If Cyrillic "т" becomes a Cyrillic "m" then everything is correct, because the title series' title (and the "subject" on My Recent Edits) are displayed in italics and "Метро 2035" correctly becomes "Mempo 2035". Jens Hitspacebar 19:14, 12 March 2016 (UTC)

Duh! :) I am not sure I like it, but the only way around it is to get rid of the italics, which seems like a high price to pay. Ahasuerus 19:59, 12 March 2016 (UTC)

No need to get rid of the italics! If that's the way Cyrillic works, that's the way it works. It's was just extra-confusing that the italic version looks like the latin character "m", though it actually isn't one. I guess people who know Cyrillic know what's going on. Sorry for the hassle, seems like I need to start to learn Cyrillic properly... Hitspacebar 22:05, 12 March 2016 (UTC)

I suspect that the problem is more wide-ranging than just Cyrillic. If the cursive form of a letter in [pick your favorite alphabet] differs from its regular form, it will cause our data to appear differently depending on whether we use italics. More likely than not, it will confuse those who are not familiar with the alphabet in question just like Cyrillic confused you. Ahasuerus 23:58, 12 March 2016 (UTC)

As for the answer regarding #2 above, I see the point regarding titles and try to rephrase my question: isn't it an inconsistency if the ISFDB main page displays "Selected Forthcoming Books" (=publications), but there's no hint about forthcoming publications on the summary bibliography and title page (except if it's a new title)? One could use a different label to distinguish from new titles, e.g. "[new forthcoming publication: DATE]" next to the title, instead of "[forthcoming: DATE]". That way one could immediately see all titles with forthcoming books on the summary bibliography and title page. Just an idea.... Hitspacebar 19:01, 12 March 2016 (UTC)

No inconsistency there. When we use "forthcoming books" on the front page, we don't mean new works. It may actually be a new work but that's not the purpose of the listing. And again, the purpose of the author's summary page isn't supposed to be for listing new publications. It only highlights works which have never been published. And since you ask, I personally would not like the author's summary page to highlight titles which have forthcoming publications. It's not the purpose of the ISFDB to promote publications, only to record them when published. That's why the ISFDB has limited forthcoming publications to a 90-day window. Mhhutchins|talk 21:13, 12 March 2016 (UTC)

I believe all the technical aspects of this issue have been adequately covered, however, this underscores how work titles are inconsistently displayed at different places (title names on author record pages being italicized vs. on title record pages and anywhere else). This brings up a point that I eventually wanted to breach here (although it might be better as a policy discussion). Is there really a "high price to pay" for "get[ting] rid of the italics"? What exactly is that? Why are we italicizing or bolding anything? Well of course in the general sense we use such styling to organize and emphasize data on the page but which items should we choose to style how? Unfortunately this is where things get sticky. I believe our current style partially (as we do this inconsistently) adheres to style guidelines originally intended for English content. So when to use such styles is dictated by cultural values. Now that we are including content from a large number of cultures should we not investigate and try to adhere to to the cultural norms for displaying data in each language? For example, I know many native Japanese would consider the large amount of italics used on title listings on Japanese author pages to be useless and make it harder to read (this is commonly true for any language that uses such a character system like Chinese too). Even popular English style guides suggest italicizing only the titles of major works (like novels) and quoting the titles of minor works (like short fiction). I believe this comes from wanting to italicize publication names not work names. In any event, I believe we should visit this topic and look at better ways to handle this (like using HTML lang attributes and CSS classes) and attempt to be more consistent in how we style titles across cultures and languages (and perhaps across different types of works too). Uzume 15:36, 14 March 2016 (UTC)

Probably off-topic and deserving a separate post, but I agree that title display should be consistent at all levels: i.e. on the author / title / publication / series pages. And for that very reason (consistency), the display shouldn't be dependent upon the language of the publication. The language of the database and its records doesn't have to be correlated to the language of the publications being recorded. Mhhutchins|talk 16:56, 14 March 2016 (UTC)

I was not suggesting the display and style of the interface should change with the language of the works (or the publications of such) cataloged (if we ever support multilingual interfaces we can face that then) but that the name of the titles themselves (which are in multiple languages) should be displayed and styled based on which language being captured in the name of the work (e.g., in the issue cited above the apparent characters changed based on it being italicized which is different that what the actual publications have on them; such alterations might be encouraged by one such culture such as English and discouraged or irrelevant by another). Uzume 18:49, 14 March 2016 (UTC)

I am not 100% sure that I understand your proposal correctly, so let me confirm my understanding using an example. Robert A. Heinlein's Summary page lists 9 variants/translation of "Misfit". One of them, "不適格", is in Japanese. Would you be in favor of not italicizing it? Ahasuerus 19:15, 14 March 2016 (UTC)

I thought I would make a more substantial post on rules and standards discussions, but to answer your question, effectively yes (but IMO more importantly marking the content with the appropriate HTML language tag which allows browsers to render such in language specific ways, e.g., different fonts, etc.). Uzume 03:10, 15 March 2016 (UTC)

The Rules and Standards board is generally used for discussions whose outcome may change our Help pages. Discussions that may result in Feature Requests are generally handled on the Community Portal.

Also, please keep in mind that technical details are best reserved for the Development page. Posting them here can discourage non-technical editors from participating because they quickly become lost. Ahasuerus 00:02, 17 March 2016 (UTC)

OK, we can talk about how to technically implement such at another place but my concern is about things like, wikipedia:Han unification#Examples of language-dependent glyphs, where different languages represent the same Unicode point differently and browsers will choose different fonts, etc. based on the language tags applied. Currently we apply none. Whether to italicize or not is only a part of the culture differences needed to represent such things properly. Uzume 02:44, 22 March 2016 (UTC)

Interesting reading, thanks. I was not aware of this issue and the surrounding controversy.

To use simplified non-technical language, the gist of it appears to be that even though certain characters (using the term "character" loosely) are shared by multiple East Asian languages, they are supposed to be displayed somewhat differently depending on the language. When the ISFDB software builds a Web page and sends it back to the user's browser to be displayed, it needs to let the browser know which language each character is a part of. If it doesn't, the browser will display the default version, which may not be correct for the given language. Is that about right? Ahasuerus 02:50, 23 March 2016 (UTC)

Yes, exactly. My thoughts on how to implement this were to add HTML language attributes as well as classes, e.g., "title short-fiction", "title novel", etc. This way we can write CSS to add italics (or whatever other styles we want) on a language and class basis. This would allow us to italicize some titles based on title type and language (and we could add other styles too like presentational quotation marks based on language, etc. if we want to get fancy). It also allows users to write their own local style sheets to override things to style them differently within their own browsers. An issue to consider is how to do a similar thing for other content in our system. We currently have no convenient automatic means to determine content language for many fields where we allow multiple languages, e.g., how would be add HTML language attributes to publisher names so they can be rendered correctly? Nothing is perfect though (multilingual books with multilingual titles are possible; in such a situation how does one mark which parts of the title are what language?). Uzume 02:30, 24 March 2016 (UTC)

Extended downtime on 2016-03-13 and server IP change

Please note that the extended server downtime on 2016-03-13 resulted in a number of changes. The server has more disk space and more memory now and its IP address has been changed. The IP change should have been transparent to most users, but anyone who is using the hack posted by Marc Kupper on 2015-01-03 will not be able to connect to the server until s/he undoes the hack. I have posted a warning on the ISFDB blog. Ahasuerus 00:22, 15 March 2016 (UTC)

Handling future dates - software changes

A few years ago we added pop-up validation to most of our data entry forms. One of the added checks was to make sure that entered years were between 0001 and 2020 (8888, 9999 and 0000 are considered special cases.) It seemed like a good idea in 2013, but we are getting uncomfortably close to 2020, at which point, of course, that logic was liable to fail. Think of it as a "Y2020" problem :)

The last patch, which I installed a few minutes ago, changed the way year validation works. You can now enter years between 0001 and (current year+1). In practical terms what this means is that editors won't be able to enter "2018" dates until 2017-01-01.

Please note that the change was fairly straightforward, but it affected a number of different software components. If you notice "dates behaving badly", please post your findings here. Ahasuerus 01:18, 15 March 2016 (UTC)

I'm far past the age when "dates behaved badly". :) —The preceding unsigned comment was added by Mhhutchins (talk • contribs) 01:24, 15 March 2016 (UTC).

Me, too. My date always behaves amazingly well. ···日本穣 · 投稿 · Talk to Nihonjoe 05:33, 15 March 2016 (UTC)

Well, since we're not supposed to enter titles more than 90 days out from publication (as a general rule), I don't see that as a problem. :) ···日本穣 · 投稿 · Talk to Nihonjoe 05:33, 15 March 2016 (UTC)

Fantastic Fiction

Is there a reason why credits for cover images from fantasticfiction.com differ from the credit given for author photos? (See this author) Does the linking permission only apply to their cover files and not their photo files? Mhhutchins|talk 21:19, 16 March 2016 (UTC)

They have changed their domain name from "fantasticfiction.co.uk" to "fantasticfiction.com". I have adjusted our software to recognize both domain names, so we should be OK for now. I suspect that they will stop redirecting old addresses in the foreseeable future, at which point we will want to do a mass migration of our URLs to the new domain name. Ahasuerus 23:39, 16 March 2016 (UTC)

And they have a separate domain for their image files: img.fantasticfiction.com. Mhhutchins|talk 00:03, 17 March 2016 (UTC)

Technically, it's a subdomain. Our software automatically parses subdomain names and credits the proper organization. Ahasuerus 00:14, 17 March 2016 (UTC)

Ahasuerus wrote "I suspect that they will stop redirecting old addresses in the foreseeable future". At present there are no plans to stop redirecting. --Marc Kupper|talk 19:46, 19 March 2016 (UTC)

Great, thanks! Ahasuerus 20:19, 19 March 2016 (UTC)

Help! Magazine, non-genre or spec-fic?

I'm copying here a portion of a discussion on a user's talk page to get a group consensus on how this periodical should be handled. Mhhutchins|talk 21:17, 17 March 2016 (UTC)

I have entered the first issue. Please take a look at it, if all is as you would have entered it (there was also the Serling story to be found). Please submit any relevant changes.

Would you like to get more involved (adding other issues, establishing a magazine series)? Ask here or on the Help Desk for any information you need. Thanks again for that magazine! Stonecreek 20:22, 3 March 2016 (UTC)

Editor field should be entered as "Editors of Help!" based on the ISFDB standard concerning non-genre magazines. Mhhutchins|talk 05:24, 4 March 2016 (UTC)

This turns out (without knowing the majority of issues) as that this ia a genre magazine: the texts seem also to be reprints of speculative fiction. Stonecreek 09:57, 4 March 2016 (UTC)

Just because it reprints spec-fic doesn't make it a spec-fic magazine. Looking through the scans convinced me of that. It's a satire/humor magazine, like Mad magazine for adults, a kind of forerunner to National Lampoon. If this is a spec-fic magazine, then so is Playboy which published original spec-fic quite regularly during the same time period as Help!. If we were to deem Help! as a spec-fic magazine, then all of its contents are eligible for entry into the database. If you're not willing to go that far, then the editor credit should be changed back. Mhhutchins|talk 15:04, 4 March 2016 (UTC)

Well, the difference to the other magazines mentioned is that it published sf and most of the other contents seem to be speculative in content as well. A rough estimate provides one with 1.65 times the relevance for ISFDB as Omni, for which much of its non-sf contents aren't speculative at all. Stonecreek 11:09, 5 March 2016 (UTC)

I think "Help!" is in the genre of humorous satire but the editor and creative people involved had a strong leaning toward the speculative. There is a slight problem with classification insofar as "speculative" is not a closed system but actually has blurry borderlines leading into fantasy, science fiction, satire, horror and so on. "Help!" touches upon a whole bunch of genres which, in turn, touch upon the speculative. However the main thrust of the magazine is humorous satire. --Speculativism 21:33, 6 March 2016 (UTC)

I agree that this is the way it shines into anyone's eye, but the fiction titles (which seem to be speculative throughout) also appear as the anchor titles and take about the half of each issue (even more than that), which isn't that far away from a regular 'pure' genre magazine, if you consider that lots of such a magazine isn't filled by fiction at all but by ads, editorials, essays, reviews, listings and artwork. Stonecreek 13:23, 11 March 2016 (UTC)

[unindent] If you're not going to consider the opinion of the person who created the record, perhaps you will that of several well-known bibliographers in the field, none of which list this title as a speculative fiction publication in their reference works: Donald H. Tuck, Mike Ashley and Marshall B. Tymn, William G. Contento and Stephen T. Miller, and John Clute and Peter Nicholls. If you believe this is a spec-fic periodical, you should enter all of its contents into the database, not just the fiction. If not, then you should consider bringing the issue before the community to form a consensus of opinion. Mhhutchins|talk 18:22, 11 March 2016 (UTC)

Yes, please, when may I expect the bundle? (Which I'd need to enter all of the contents.) Stonecreek 10:43, 17 March 2016 (UTC)

Why don't you follow the link which was given above to scans of the issues? Isn't that where you got the original information for this record? Mhhutchins|talk 21:09, 17 March 2016 (UTC)

This was the source I used, yes. But unfortunately the authors/artists aren't as easily identifiable with this source as one would wish for, although the speculative content is! Stonecreek 21:29, 17 March 2016 (UTC)

In earnest: do the sources you mention list Omni, and if so, then please ask yourself, why don't they list this magazine?. If you go ahead and modify Omni into a non-genre magazine then there would be some reason in your argumentation. Stonecreek 10:47, 17 March 2016 (UTC)

All of the references I cited include Omni except for Tuck (who only covered publications through 1968). So I ask myself why don't they include Help!? Very likely because it isn't a science fiction magazine! Don't you think such authoritative figures in the field should know? Omni promoted itself as "the trail-blazing magazine of science and science fiction," so it's only natural that the ISFDB not handle it as a non-genre publication. As to your last point, why should I modify almost 200 publication records, removing hundreds of content records and deleting them from the database, just to convince you that Help! is not a science fiction magazine? Mhhutchins|talk 21:09, 17 March 2016 (UTC)

And to be clear. This discussion isn't about the publication's eligibility. I'm asking that it be handled as a non-genre magazine. Mhhutchins|talk 21:19, 17 March 2016 (UTC)

Yes, that wasn't the question. But Omni isn't a magazine of speculative fiction either. It's clearly a magazine on and about popular science. Help! has the higher percentage of speculative fiction per issue than Omni and the other material is almost exclusively also speculative (apart from editorials and letter columns). Stonecreek 21:22, 17 March 2016 (UTC)

This isn't about Omni. The case for its inclusion in the database as a genre magazine has already been clearly made. Stop the obfuscation and tell me how Help! is a science fiction magazine. And if it is, why aren't you adding all of its contents to the database as established by ISFDB standards? Mhhutchins|talk 21:46, 17 March 2016 (UTC)

(unindent) Before the discussion gets too heated, let's take a step back and make sure that all of us, including new editors who may not be intimately familiar with ISFDB policies, are on the same page.

The ISFDB project makes a distinction between "genre" and "non-genre" magazines. The rules for entering them are quite different -- see Help:Entering non-genre magazines for details. Whenever we encounter a new magazine, we must first determine whether it's "genre" or "non-genre".

As the linked Help page explains, a non-genre magazine is "one that did not specialize in Science Fiction, Fantasy, or Horror, or any other form or forms of speculative fiction, but included much fiction and other content that was not speculative fiction." I am not familiar with "Help!", but it would appear that one of the issues with it is whether the borderline speculative nature of the magazine -- I am referring to the comment that it "touches upon a whole bunch of genres which, in turn, touch upon the speculative" above -- should be taken into account when deciding whether it's "genre". Personally I am not sure it would be a good idea since we would then have to include magazines like The Journal of Irreproducible Results, which specializes in faux science and related humor. Ahasuerus 01:36, 18 March 2016 (UTC)

A "genre" magazine isn't necessarily a speculative fiction magazine, even though we use the term "non-genre" to refer to any periodical that isn't a speculative fiction magazine. Perhaps we should refine our terminology and change the current usage of "non-genre" magazine to "non-speculative fiction" magazine? That would make the point more clear to the casual contributor to the database. Mhhutchins|talk 04:13, 18 March 2016 (UTC)

Another question that comes to mind is whether we have ever determined how much speculative fiction a magazine must contain before it qualifies as a "genre magazine". Or should we use other, non-quantitative criteria as well (or instead)? Ahasuerus 01:36, 18 March 2016 (UTC)

To answer these last two questions: no and yes. There are many definitive resources that have pretty much done the work for us: Donald H. Tuck, Mike Ashley and Marshall B. Tymn, William G. Contento and Stephen T. Miller, and John Clute and Peter Nicholls. Any periodical that isn't included in these references should be discussed on a case-by-case basis. As we're doing here. Anyone with an internet connection can go to the scans of Help! linked above and join the discussion. Mhhutchins|talk 04:13, 18 March 2016 (UTC)

Sorry, Michael, but I'm not obfuscating anything, merely putting Help!, which clearly anchors its publications and its contents page with speculative fiction, into perspective in regards to Omni, which usually doesn't its anchoring with speculative fiction (unless it's a big name author). And the perspective is this: why should a magazine clearly more relevant for us (because more than 90% are speculative) be not considered as genre when a popular science magazine is? Stonecreek 05:00, 18 March 2016 (UTC)

To add to the perspective, here are the likenesses and differences for the two magazines:

Likenesses: The shortfiction both publish is speculative in content, and both publish almost exclusively fiction by authors located at the heart of ISFDB (and, Ahasuerus, for that reason both magazines should be distinguished from The Journal of Irreproducible Results).

Difference 1: - Help! is a speculative magazine publishing speculative fiction and speculative cartoons on a par (anchoring itself on all the fiction and some major cartoons), whereas Omni is a popular science magazine that garners its pages with speculative fiction (the ratio of spec. fic. is higher for Help! than for Omni).

Difference 2: - Omni's published fiction can overall be considered as science fiction, whereas Help! publishes fantasy (Ray Bradbury, fiction from Arthur C. Clarke's 'White Hart' series, Saki, H. G. Wells etc.) and satirical science fiction (Algis Budrys, Robert Sheckley, William Tenn).

One can only guess why this magazine was not considered as worthwhile for the various indexes and bibliographies: the main reason seems to be that it doesn't have a speculative appearance and so the editorial work wasn't recognized as speculative, whereas Omni does appeal to the science fiction reader's eye, but can't be considered as speculative (for its a popular science magazine).

I'd think ISFDB doesn't rely on superficial appearances but on a magazine's contents. Stonecreek 08:04, 18 March 2016 (UTC)

The Last Robot by Isaac Asimov

The translation of 最後のロボット is "The Last Robot" or "The Final Robot", but I can't find a story by Asimov that is close to that. Anyone have any ideas which one this might be? It was about 22 pages long when it ran in S-F Magazine (pp.397-419). Thanks! ···日本穣 · 投稿 · Talk to Nihonjoe 22:55, 17 March 2016 (UTC)

Maybe it's Little Lost Robot? Stonecreek 08:18, 18 March 2016 (UTC)

Maybe. Since all I have to go by is the title, it's really difficult to tell. ···日本穣 · 投稿 · Talk to Nihonjoe 15:24, 18 March 2016 (UTC)

I'd link it to —That Thou Art Mindful of Him! based on amazon.co.cp which has scans of the table of contents pages with the first of the two pages of contents having in English "The Thou Art Mindful of Him!" by Isaac Asimov © 1974.^[6] I checked both pages and the only Isaac Asimov (アイザック・アシモフ) story in that issue seems to be 最後のロボット which is the one we are trying to link up. --Marc Kupper|talk 06:18, 19 March 2016 (UTC)

Heh. That's what I get for focusing on only the Japanese of those pages. Thanks. :) ···日本穣 · 投稿 · Talk to Nihonjoe 14:58, 19 March 2016 (UTC)

I am happy to see some major Japanese magazines finally starting too have a presence here. BTW, the sources I see also confirm Marc's assertion:

「最後のロボット」The Thou Art Mindful of Him! 風見潤・訳《ＳＦマガジン 1975年７月号》 from http://homepage2.nifty.com/te2/w/w01.htm#w00506

Notice that also mentions the translator as 風見潤 (Jyun Kazami). Thank you. Uzume 21:16, 21 March 2016 (UTC)

Advanced Search changes - 2016-03-17

Advanced Search has been changed to allow specifying how the entered search value(s) should match what's in the database. The supported values are "is exactly", "contains", "starts with", and "ends with". The default value is "is exactly", which tends to be somewhat faster than the other three options. You can still use the listed wildcards if you need to be more specific.

The new functionality is available for all fields on the Advanced Search page. The only exception is the ISBN field in the Advanced Publication Search. The details are documented in the Publication section of the Advanced search page.

As is always the case with complex changes, there is a decent chance that something was overlooked. If you see anything unexpected, please describe your findings here. Ahasuerus 01:12, 18 March 2016 (UTC)

Thank you! This seems to handle the issues raised in #Advanced Search - wildcards for publication searches above. A publication price search for ___-___ shows for example that there are three records that have a date or ISBN in the price field. This search finds dates/ISBNs in the page count field. --Marc Kupper|talk 06:33, 19 March 2016 (UTC)

Excellent! :) Ahasuerus 13:29, 19 March 2016 (UTC)

I am curious, how are these any different from just adding "%" wildcards at the beginning and end (where appropriate) of the match field? Uzume 01:23, 22 March 2016 (UTC)

You are quite right that "begins with" and "end with" are functionally equivalent to adding a wildcard to the search string when using "is exactly". However, a lot of people do not have a working understanding of wildcards, which is presumably why this functionality was originally requested. Ahasuerus 20:19, 22 March 2016 (UTC)

Kurd Lasswitz or Kurd Laßwitz

Just a minor thing: it just occured to me that "Kurd Lasswitz" is the current canonical name used for this author here. However, if I'm not overlooking something, "Kurd Laßwitz" (which is a pseudonym only at the moment) should be the canonical name because that's the name which was used for almost all German (his working language's) publications. Considering the quite low ID of the author's record I assume that it is quite old and the current canonical name was entered at a time when features like translations and/or pseudonyms weren't implemented yet, and therefore the name used in English publications was used. Jens Hitspacebar 15:41, 19 March 2016 (UTC)

I agree that the relationship should be reversed. (Just look at the overwhelming number of "only appeared as" credits which is usually a clear indication that the relationship has been incorrectly set-up.) The problem is that there is no quick fix. It will take many, many submissions to correct it. The same problem, multiplied exponentially, is here for James E. Gunn, who has published far more as "James Gunn" for a greater percentage of his writing life. Maybe someone (Ahasuerus) can come up with a software program to reverse relationships, but I can't imagine it would be easy. Mhhutchins|talk 16:10, 19 March 2016 (UTC)

Feature Request 166 asks for "mass variant title creation for Authors". Unfortunately, as Michael suggested, it won't be easy to implement. I have given it some thought, but the number of permutations is kind of daunting. Ahasuerus 20:25, 19 March 2016 (UTC)

I can imagine that! It's not just swapping the pseudonym record and canonical record but also taking care of, and in some cases deleting (in case of Kurd Laßwitz deleting almost all of), the variants. Good to see it confirmed that "Kurd Laßwitz" should be the canonical name. Jens Hitspacebar 21:16, 19 March 2016 (UTC)

This will quickly get worse too as more and more non-Latin content gets entered and is forced to use Latin author names, eventually when we get non-Latin canonical author name support there will be a large amount of content to convert. In some of those cases we might be able to just change the canonical name but that is dangerous as there are often many translations that might actually credit works in Latin. I can foresee a mess in untangling them in the future. The same can be said for original Latin language works translated into non-Latin languages. Uzume 21:31, 21 March 2016 (UTC)

I agree that it will be messy, which is why I am trying to add software support for non-Latin author names ASAP. The sooner we switch, the fewer records we will need to convert. There are approximately 1,340 "non-Latin" authors (1%) and 4,200 "non-Latin" titles (0.3%) in the database, so it's not too bad yet, but it will be a significant effort nonetheless.

We are finally moving full speed ahead with the Wiki-to-database conversion, which means that I can start working on adding "Notes" and "Biography" fields to Author records. Once that has been done, I can add support for "transliterated" canonical names, update Author Directory and then we can start the conversion effort. Ahasuerus 20:31, 22 March 2016 (UTC)

I appreciate the update but I was not trying to hurry things along just underscore the issue (e.g., if I develop a bot to push pubs in from some major source like Amazon JP this could get large very fast). Uzume 01:23, 23 March 2016 (UTC)

Suspected Latin/Non-Latin Publisher Name Issues

(moved from the Moderator Noticeboard since these reports can be accessed by all editors)

Re this clean-up report: I'm not sure what issues this list finds and how to fix them. For example, why would so many English-only publishers be listed here? Mhhutchins|talk 19:21, 20 March 2016 (UTC)

An example. The list produces 'The Oxford University Press', but does not mention the publisher 'Oxford', which should have been on this list, IMHO.--Dirk P Broer 21:17, 20 March 2016 (UTC)

This report -- and the other two "Latin/non-Latin" cleanup reports -- identifies two types of potential problems.

First, it looks for publisher names which:

use non-Latin characters, and
do not have at least one transliterated name on file

For example, C. B. Кульженко was an early 20-th century Russian publisher and アスキーメディアワークス is a Japanese publisher. Once we enter their transliterated names, the records will no longer appear on this report.

Second, it looks for publications whose titles use a language associated with a non-Latin alphabet/script. It then checks the publisher record to see if its name is spelled using Latin characters. If it is, then the publisher is considered suspect and is added to this report. Of course, it's possible for a Japanese, Russian, etc publisher to use Latin characters in its name, e.g. "SF 2000", which is why moderators have the option to "ignore" publisher names.

The reason why international publishers like Oxford University Press appear on this report is that they have presumably published books in non-Latin languages. On the other hand, it's also possible that one or more of their books have had an incorrect language assigned when we entered the data. There is no way to view a publisher-specific list of exceptions at this time, but I am going to add this functionality shortly. Ahasuerus 21:36, 20 March 2016 (UTC)

I just fixed a few of them. Some I can't fix:

Jitsugyō no Nihon Sha needs to have the name changed to 実業之日本社.

Kōbunsha needs to have the name changed to 光文社.

I'm sure there will be others. ···日本穣 · 投稿 · Talk to Nihonjoe 22:22, 20 March 2016 (UTC)

Changes made, thanks! Ahasuerus 22:32, 20 March 2016 (UTC)

I changed the note for Chuokoron-Shinsha , and the title of that needs to be changed from Chuokoron-Shinsha to 中央公論新社.

~~Enterbrain needs to be merged with エンターブレイン.~~ see below

Futabasha needs to have the name changed to 双葉社.

Gakushu Kenkyu Sha needs to have the name changed to 学習研究社.

Genkōsha needs to have the name changed to 玄光社.

~~Gentōsha needs to be merged with 幻冬舎.~~ see below

Hōsei Daigaku Shuppankyoku needs to have the name changed to 法政大学出版局.

Haikasoru needs to be removed from the list as they only publish in English (they translate from Japanese to English, so Japanese may occasionally be in a title).

Nihon Hyōronsha needs to have the name changed to 日本評論社.

Ota Shuppan needs to have the name changed to 太田出版.

Sanrio needs to have the name changed to サンリオ.

SF Materials Research Association needs to have the name changed to S-F資料研究会.

Shōdensha needs to have the name changed to 祥伝社.

I'll watch for more. ···日本穣 · 投稿 · Talk to Nihonjoe 22:26, 21 March 2016 (UTC)

Speaking of such things since you brought up アスキーメディアワークス, I notice someone set a transliteration of that to "ASCII Media Works", however that is not strictly a transliteration (where as "Asukī Media Wākusu" is) but more an English translation. That said, the name is definitely meant to be interpreted as the Japanese counterpart to that English name. Is this acceptable (there can be multiple transliterations of course but do we consider "ASCII Media Works" to be such in light of the Japanese name that is meant to be interpreted like that)? In this case, it is not that big of an issue as there should be a publisher merge with アスキー・メディアワークス. Uzume 21:41, 21 March 2016 (UTC)

I submitted a correction for the only title under アスキーメディアワークス, changing the publisher to アスキー・メディアワークス (as they use the ・ in the actual publisher title). If the publishers work the same way everything else seems to, then once that submission is approved there will be no records under it. With no records, it should be deleted. ···日本穣 · 投稿 · Talk to Nihonjoe 22:30, 21 March 2016 (UTC)

Yes, since there was only a single publication record that was the way I intended to merge them but my question still stands (エンターブレイン also has this issue). Incidentally, ハヤカワ文庫JA needs to be merged with ハヤカワ文庫・JA (but of course we have no actual merge function for that presently so a bunch of pub records need to be updated). Uzume 00:57, 22 March 2016 (UTC)

I updated all of the ハヤカワ文庫JA to ハヤカワ文庫・JA. I also submitted changes for both Gentōsha entries to change the publisher to 幻冬舎, so that should fix those ones and get rid of the old entry. It looks like Enterbrain no longer exists, so that takes care of エンターブレイン. ···日本穣 · 投稿 · Talk to Nihonjoe 05:26, 22 March 2016 (UTC)

I posted the list above over to the Moderator's Noticeboard. ···日本穣 · 投稿 · Talk to Nihonjoe 18:34, 23 March 2016 (UTC)

Wiki-to-Database migration: Publication and Publication Talk pages

(moved from the Moderator Noticeboard since these cleanup reports can be accessed by all editors)

4 new cleanup reports have been deployed as part of our Wiki-to-database migration effort. Once they run overnight, they should find the following Wiki pages:

399 Publication-specific pages
13 Publication Talk pages
8 Publication pages with no associated publication

Some of these Wiki pages can be deleted outright while certain others will need to be folded into their respective publications' Notes fields. The "{{BREAK}}" functionality which was added a few months ago may come in handy when migrating long notes. Ahasuerus 01:25, 19 March 2016 (UTC)

I'm not sure what's expected to be done here. I've always assumed that the reason why wiki bibliographic comments pages were created was because the editor felt the information wasn't needed in the publication record's note field. I've created only a few of these pages, so I'm not entirely sure of the motivations of others (like Marc Kupper who created many pages like this one.) What's changed in that regard that we need to burden a publication record with such extraneous and sometimes clumsily assembled and researched data, suppositions, and conclusions? Aren't note fields supposed to contain data that is present in the books themselves? In the first listing on the clean-up report, you'll find a link to this wiki page. How is that supposed to be migrated to the publication record? Mhhutchins|talk 18:01, 20 March 2016 (UTC)

I'm coming across some wiki publication pages which contain duplicate data or inquiries that can obviously be deleted. Others...well, I'll leave them alone for now. Mhhutchins|talk 18:06, 20 March 2016 (UTC)

I understand the stated desire to remove the wiki and instead have all the information in the database. However, I think we need to take a step back and think about the design first. I don't agree with jamming all this information into the publication notes (even under a break tag). If the end goal is to get rid of the wiki, then new functionality should be added to the database to support that (some type of 'publication talk page' equivalent). -- JLaTondre (talk) 18:23, 20 March 2016 (UTC)

That's basically my argument, but thanks for making it clearer. Mhhutchins|talk 18:33, 20 March 2016 (UTC)

Reviewing the two Wiki pages linked above, I see what appear to be two separate issues.

The first one is raised by Michael's first example, which contains detailed publisher data from the linked pub's copyright page. It was created by Marc back in 2008, apparently as part of the "experimental Verified Publishing Names project". The project was suspended in late 2008 when its project pages were last edited. Some of the data gathered by the project may be reusable if and when we add support for publisher hierarchies, but I don't think it's something that we need to keep at the publication level. I'll invite Marc to stop by and comment, but my first inclination is to move the contents of similar Wiki pages to that Project's pages.

The other issue is raised by Michael's second example. The tabular data listed on that Wiki page is a listing of all known Signet printings of 2001: A Space Odyssey in support of the notion that the publication in question couldn't possibly be the 13th printing. I believe the presented data could be summarized along the following lines:

Primary verified as the 13th printing by an inactive editor. However, the listed price ($2.95) is much higher than that of the 12th and 19th printings ($0.95). According to Locus, the 30th printing was published in 1984-02 and the price was $2.95, so this is presumably the 30th, or possible the 31st, printing."

I would then delete the Wiki page.

Re: the proposal to add "some type of 'publication talk page' equivalent" field to publication records, I am not sure that the numbers support it. The ISFDB database contains approximately 404,800 publication records at this time. 399, i.e. less than 0.1%, records had associated Wiki pages two days ago. By the time we are done with the low-hanging fruit, most of them will be gone. If we decide that a particular publication-specific Wiki page is worth preserving even though it can't be easily folded into the Notes field (images?), we can keep the page and link to it from the Note field. That will still let us get rid of the "Bibliographic Comments" link, which is the main goal here. Ahasuerus 00:13, 21 March 2016 (UTC)

I understand we can link to the wiki page in the Note field, but how do we then remove the "Bibliographic Comments" link from the record's metadata section? Will that function be removed entirely from the publication record's display? If so, the sooner the better, so that we're not taking two steps forward and one step backward in trying to migrate or remove these wiki pages. Mhhutchins|talk 01:58, 21 March 2016 (UTC)

Yes, the plan was to remove the "Bibliographic Comments" link from the Publication page once the cleanup report was, well, cleaned up. Give that we have accumulated roughly 400 publication-specific Wiki pages in the last 9+ years, I don't expect that we will get many more in the next few weeks. That said, I can certainly remove it tomorrow. Ahasuerus 02:12, 21 March 2016 (UTC)

The wiki notes associated with publication records have been used for additional data about a publication that both is not necessary as part of the minimum set of information we capture in a publication record and would take up screen space on the main record. As the information in those pages is never part of the verified data about a publication there's no need to impose moderator controls on it. We also get a far better edit history from those pages than we get from publication records plus editing is far easier for humans as we don't need to deal with HTML. In looking at my recent wiki-contributions for edits to publication pages I see:

Publication:WBSF1988 is a detailed question about a discrepancy in the publication record. As it was verified by many people I chose to post the question to the publication's page and to link the versifiers to it. As it appears nobody is able to answer the question the next step it to edit the pub notes to make it clearer there's an open question in case someone shows up with a publication that can answer the question.
Publication:BKTG23438 is also about a data discrepancy in a publication record that documents the evidence. I started to do the fix that's proposed above and realized it's more of a SNAFU than was apparent from a quick look at the wiki page. Additional stuff needs to get added to the wiki page and this is an area where having a wiki is a great thing as it's easy to make tables with either ISFDB or wiki links as needed.
Publication:GRNTE1973 is one of those publications where it turned out ISFDB and many web sites had errors. The mess exists as this is one of those revised fixup stories.
Publication:GRNTHTRNLS0000 is related to GRNTE1973 mentioned in the previous bullet.
Publication:TRPLNTRSBP1975 while I'm no longer actively doing the verified publisher names project I documented this one as the publication was all over map in terms of the names it used.
Publication:MSTRBRKLSN2006 is part of verified publisher names.
Publication:LGHTSPDRNM2011 While verifying the publication I noticed that ISFDB was not recording the awards for quite a few stories in this anthology. I did not want to get sidetracked into adding half a dozen new minor award categories with one random story in each and so documented the awards in the wiki.

Assuming you want to get rid of wiki-side publication notes entirely I'd suggest we move the notes into the author's bibliographic wiki pages for publication discrepancy issues or to the publisher pages for verified publisher name related content. I would not move any of it into the publication notes other than a single line with a link to the section on the author's wiki for those items that were moved. --Marc Kupper|talk 08:31, 21 March 2016 (UTC)

Let me first summarize the reasons behind the Wiki-to-database migration project. We have discussed them many times over the years, but it may be useful to have all of them listed here to refresh our collective memory and to get new editors up to speed:

The ISFDB database and the ISFDB Wiki are effectively two databases which can (and do) get out of sync over time. As per the summary posted below, more than a third (!) of Wiki-based Publisher pages are now orphans and not visible from the database side.
The bidirectional links between the database side and the Wiki side are based on what we used to call "lexical match", i.e. the two names/titles being the same. In our version of the Wiki software, the match doesn't work when certain characters are present, notably accented characters. This has become a bigger problem as our data has expanded to cover non-English works and authors.
There is no moderator oversight when editing the Wiki, which often results in incorrectly entered data. For example, consider this publication-specific Wiki page. The data is good, but it is related to the Birthright title rather than to one of its publications.
With the exception of ISFDB-hosted images, Wiki-based data is not included in our publicly accessible backups. If something major happens to isfdb.org and its maintainers -- and we all know that many useful Web-based resources have disappeared over the years -- the site can be recreated using the latest backup file. On the other hand, the Wiki data will be gone.
Bibliographic data is split between two Web pages, which can prevent our users from getting a full picture.

We have always known about these limitations, but early on we were forced to use the Wiki as a crutch because the core ISFDB software didn't support many features that we wanted. Over the last few years we have implemented many of these features, including Publication Series, an Award Directory, a Publisher Directory, Series/Publisher/etc notes and so on. We have also added built-in cleanup reports which have superseded Wiki-based cleanup projects.

Because of these enhancements we no longer need to use the Wiki as a crutch and can go back to using it for its original purpose, i.e. allowing editors to communicate. Of course, editors will remain free to create and maintain Wiki pages for research purposes, but Wiki pages will no longer be automatically linked based on the notorious "lexical match". Ahasuerus 21:35, 21 March 2016 (UTC)

The other major use we have of the wiki is as forum software (for hosting these sorts of comments) for which MediaWiki is actually not particularly well suited for anyway. I am sure it won't happen anytime soon but migrating away from such things will eventually allow us to fix these sorts of deficiencies (before we can even consider migrating away from MediaWiki there are several problems to unravel such as our login system which is shared and image hosting, etc. but one thing at a time. Who knows, we might accomplish such things before we get around to upgrading MediaWiki and then never need to upgrade it). Uzume 21:50, 21 March 2016 (UTC)

(A few hours later.) Sorry, I had to run before I could post the second part of my response. I will try to do it later tonight or tomorrow morning. Ahasuerus 02:07, 22 March 2016 (UTC)

On to the specific issues raised by Marc:

Re: the proposal to move the data from publication-specific Wiki pages to "author's bibliographic wiki pages for publication discrepancy issues or to the publisher pages", the main problem here is that Wiki-based Author Biblio and Publisher pages will be folded into the database as well -- see below. That said, there is nothing preventing us from maintaining "project" pages on the Wiki side, but we'll need to link to them directly from each record's Note field. I can adjust the cleanup reports to ignore publication records whose Note fields have links to Wiki pages. Ditto for other types of records except that the cleanup report will be checking for the presence of Wiki links in the multiply occurring "Web page" field.
Re: the concern that the data currently stored in the Wiki would "take up screen space on the main record". It's definitely a concern and that's why the {{BREAK}} functionality was added a few months ago.
Re: "the information in those pages is never part of the verified data about a publication there's no need to impose moderator controls on it", unfortunately, as the Birthright example that I posted earlier demonstrates, the lack of moderator oversight can lead to all kinds of issues.
Re: "We also get a far better edit history from those pages than we get from publication records", it is undoubtedly true, but the same argument applies to all of all data. If we thought that having an edit history was more important than having a structured database like we currently do, we would want to migrate everything to the Wiki.
Re: "editing is far easier for humans as we don't need to deal with HTML", I agree, but, again, it's an argument that applies to all types of Note fields. I don't think it outweighs the disadvantages listed above, but perhaps we could consider allowing Wiki codes in Note fields. There are freely available parsers that will automatically convert Wiki codes to HTML at output time.

Another thing to consider is that publication-specific Wiki pages are currently linked to ISFDB records using "publication tags" like "THRMFSPCTH1981" (not to be confused with user-defined title tags.) These tags are a leftover from ISFDB 1.0 as it existed in the 1990s. They are no longer editable and can't be easily viewed except on the "Bibliographic Comments" line. They will completely disappear once the Wiki-to-database conversion has been completed. As long as existing Wiki-based Publication pages are linked in the Note field, they won't be affected by the tags' disappearance, but we'll need to decide on a naming standard for future pages. Ahasuerus 23:40, 22 March 2016 (UTC)

At one point I looked at renaming all the wiki pages named this way (using pub tags) to using pub ids instead, however, it was a long process and I did not want to try to do it by hand. I had planned to then change the software to link using the pub ids but this will be better as we can just dispense with the wiki pages and there is no conversion (to using pub ids) needed. It should be noted the other current use of pub tags is as a default name for cover are image hosting. I also proposed changing the default to "pub<pubid>" but I asked for review for this change and for whatever reason that never made it. Since the actual images are linked by URL having old ones use names with pub tags in the name should not be an issue (i.e., they should not need to be converted). Uzume 01:55, 24 March 2016 (UTC)

Wiki-to-Database migration: Series, Publishers, Magazines, Fanzines

Additional cleanup reports have been deployed and will become available tomorrow morning. They cover series, publishers, magazines, fanzines and are similar to the publication-specific cleanup reports that are being discussed above. Here is how many Wiki pages I expect these reports to find:

Series:
- 591 Series pages
- 30 Series Talk pages
- 92 Series pages not linked to an ISFDB series record
- 11 Series Talk pages not linked to an ISFDB series record
Publishers:
- 501 Publisher pages
- 30 Publisher Talk pages
- 273 (!) Publisher pages not linked to an ISFDB publisher record
- 15 Publisher Talk pages not linked to an ISFDB publisher record
Magazines:
- 268 Magazine pages
- 15 Magazine Talk pages
- 77 Magazine pages not linked to an ISFDB magazine record
- 12 Magazine Talk pages not linked to an ISFDB magazine record
Fanzines:
- 86 Fanzine pages
- 3 Fanzine talk pages
- 29 Fanzine pages not linked to an ISFDB fanzine record

Many magazine/fanzine pages are little more than glorified issue grids created back when we didn't have software support for them; they will be easy to fold into the database. Some publisher pages are very extensive and we may end up linking to them from the database side. Hopefully, the picture will become more clear once we remove the obvious debris. Ahasuerus 00:28, 21 March 2016 (UTC)

"Publishers with Wiki pages" and "Publishers with Talk pages" both throw the same exception. Column "pubisher_id" has a typo:

 /var/www/cgi-bin/edit/cleanup_report.cgi in WikiPages(report_number=109, namespace_number=110, namespace_name='Publisher', record_name='Publisher', table='publishers', record_id='pubisher_id', record_title='publisher_name', linking_field='publisher_name', script='publisher')
 4022                                      table, record_title)
 4023 
 4024         db.query(query)
 4025         result = db.store_result()
 4026         num = result.num_rows()
global db = <_mysql.connection open to 'localhost' at 94de40c>, db.query = <built-in method query of Connection object at 0x94de40c>, query = 'select publishers.pubisher_id, publishers.publis... order by publishers.publisher_name'

<class '_mysql_exceptions.OperationalError'>: (1054, "Unknown column 'publishers.pubisher_id' in 'field list'")

Jens Hitspacebar 08:54, 21 March 2016 (UTC)

Thanks, fixed! Ahasuerus 14:49, 21 March 2016 (UTC)

Quite a few of the Fanzine Wiki pages look like mine, or ones that I worked on. I just converted 'Abstract' into a Magazine series (there hadn't been one before), and I'll continue to work on more of these as I have time. (Which, unfortunately, will be slow going.) Chavey 06:24, 22 March 2016 (UTC)

Some of those wiki pages are for fanzines which don't have publication records in the database. So this migration is going to be a greater effort that one would have first thought. Mhhutchins|talk 17:30, 22 March 2016 (UTC)

In most of those cases, though, I have full records for those zines in my own spreadsheets. And I have a script that can create and add the issues directly from the spreadsheet. So I should be able to get the full set of issues added for those. Chavey 06:00, 25 March 2016 (UTC)

(unindent)Can the cleanup report pages use UTF8 encoding? At present they have "text/html; charset=iso-8859-1" (windows-1252). I saw "è§’å·æ–‡åº«" at the end of Publisher Wiki pages not linked to Publisher records and so clicked. I was able to fix underlying issue by moving 角川文庫 to Publisher:角川書店 though see that the publisher's database page still shows a red link though if you click on it you are taken to the correct page in edit mode. The entry for this publisher is still listed on the cleanup report but I suspect that's one that's updated nightly. --Marc Kupper|talk 23:37, 29 March 2016 (UTC)

The problem here is that Wiki tables use one encoding (Unicode) while our database tables use a different encoding. As long as this remains the case, there will always be a mismatch of some sort. For example, if you pull up "Publication Series with non-Latin Names without Transliterated Names" and change your browser's "Text Encoding" setting to "Unicode", many names will have garbage characters, e.g. "Kni�nice vědeckofantastick�ch př�běhů".

Eventually we will migrate the database to Unicode, but until then Wiki-database links will remain a mess. As per my comments below, I am currently looking into ways to manage this mess better. Ahasuerus 15:58, 31 March 2016 (UTC)

"Bibliographic Comments" and "Biography" pages

I am ready to start working on enhancing the software to enable migrating Wiki-based "Bibliographic Comments" and "Biography" pages to the database. However, before we can do that, we need to decide how many new fields we want to add to Author records. The most straightforward solution would be to add two -- "Notes" and "Biography" -- which would correspond to the current Wiki pages. At one point I looked into combining them into one field, but it seemed to raise more problems that it solved. Any other suggestions?

BTW, here are the current stats:

Bibliographic Comments pages: 1,636
Bibliographic Comments Talk pages: 33
Biography pages: 1,896
Biography Talk pages: 1

Ahasuerus 20:22, 21 March 2016 (UTC)

I agree with that (where "Bibliographic Comments: Author:" becomes "Bibliographic Notes" and "Biography: Bio:" becomes "Biographic Notes" or similar). I do not think we really need author specific talk areas. They can be handled here or eventually whatever forum we come up to handle such discussions (the current "Bibliographic Comments Talk" and "Biography Talk" pages just tend to get lost, unseen and out-dated anyway). Uzume 22:00, 21 March 2016 (UTC)

I think the Biographical pages are useful in cases where an author doesn't have a Wikipedia page. And some folks, at least, look at them. On two occasions I have been contacted by researchers who discovered that biographical pages I had written had information about an author that they had been unable to find elsewhere. Chavey 04:10, 22 March 2016 (UTC)

I am sure we'll want to keep them, but I think we'll want to use {{BREAK}} liberally for anything longer than "son of Anne McCaffrey". Ahasuerus 04:31, 22 March 2016 (UTC)

I did an experiment using {{BREAK}} in a publication note. For publications no additional field would needed unless you want to add a Publication Comment field that you would need to click to view. Pub notes have usually only been used to document the printing number and to document the sources for the existing database fields. The publication comments have tended to be used for extraneous material that does not fit in with how we use the notes and so it makes sense to have a separate publication comments field. Nothing needs to be added at the title level as they already support BREAK in notes meaning we can move something like the Birthright note into the title.

I believe adding an author biography field that works like publisher notes (meaning it's displayed by default if it exists) would be of value. We could then do the "son of Anne McCaffrey" with a BREAK if more needs to be said. We should also have an author bibliographic comments field that is not displayed and in instead you click it to view it. Publisher pages likely can be migrated straight into the existing publisher notes field using BREAK which is already supported. The main thing of bibliographic value on publisher pages is the documentation of the ISBN ranges. The verified publisher name project data can be scrapped at both the publisher and publication level though I'd like to keep the data on the wiki for a while.

Chavey brought up "On two occasions I have been contacted by researchers". I too have been contacted several times over the years and that's one value to having our names in the wiki style notes. Someone out on the Internet who finds one of our pages should be able to figure how who is the best person to contact for supporting details. I'm not sure how to best resolve that. 02:44, 29 March 2016 (UTC)--Marc Kupper|talk

I personally believe we should step back and further assess the notion that everything on the wiki has to be moved to the database. There are cases where that's just not feasible, and forcing such information into the database just makes it cluttered, bloated, and impractical. I have decided not to work on any of the new clean-up reports until there is a more thorough discussion about this migration of data and whether the work it's going to take is an efficient use of our time and resources. Mhhutchins|talk 03:14, 29 March 2016 (UTC)

Is there a way we can not transfer the data, but instead have the database simply display the text contents with the record instead of having it link to them? That would allow the text to remain in the wiki (retaining the list of those who contributed it), and also display it. ···日本穣 · 投稿 · Talk to Nihonjoe 15:31, 29 March 2016 (UTC)

I came back to this thread as I was looking at a magazine issue grid, spotted "Bibliographic Comments: View/edit existing Series comment" at the top of the page, realized I had not mentioned series notes above, clicked and my first thought was horror (speculative of course) at trying to create and maintain a very nice looking page in raw HTML.

The main database captures a set of useful information. With the exception of author biographies, the wiki pages contain material that's auxiliary to the database. It's a combination of unstructured text and some structured data in tables and lists. The main issue seems to be that wiki pages are getting disconnected from the database records they were supporting. In the previous thread Ahasuerus documents the state of things for some types of wiki pages. I'll summarize that here:

92 of 591 (16%) series pages are not linked to an ISFDB series record.
273 of 501 (54%) publisher pages are not linked to an ISFDB publisher record.
77 of 268 (29%) magazine pages are not linked to an ISFDB magazine record.
29 of 86 (34%) fanzine pages are not linked to an ISFDB fanzine record.
471 of 1446 (33%) total of the wiki pages are not linked to an ISFDB record.

I don't see the numbers for orphan author biography, author bibliography, and publication graphic comment pages and so did not include those in the summary.

I have no idea if it is possible or practical for the main database code to make changes to the wiki database when the information the wiki side needs to link back to the database changes. --Marc Kupper|talk 22:59, 29 March 2016 (UTC)

(unindent) I haven't forgotten about this issue. I am currently experimenting with a few different options and will post once I have the results. Ahasuerus 20:11, 30 March 2016 (UTC)

Japanese prices

I was wondering if we want to standardize on a symbol for entering Japanese prices. I ask this because of the results of this search:

http://www.isfdb.org/cgi-bin/adv_search_results.cgi?USE_1=pub_price&OPERATOR_1=contains&TERM_1=%26%2365509%3B&ORDERBY=pub_title&START=0&TYPE=Publication

Help:Screen:EditPub#Price mentions (the halfwidth) "¥" but not (the fullwidth) "￥" (this is a different Unicode character). And while we are at it, perhaps we should mention "円" (not often used outside of Japan) and "圓" (an older variant of the previous from before World War II) too. I am also hoping we do not have any fullwidth numbers in prices too but I suppose I should check. Thank you. Uzume 01:46, 22 March 2016 (UTC)

All numbers, symbols, and letters that have halfwidth versions should be using the halfwidth versions. I do my best to catch all of them, but when typing them, I sometimes overlook them and accidentally enter the fullwidth version. I think I've caught all of them, however. As for the yen symbol, I think "¥" should be used (halfwidth). ···日本穣 · 投稿 · Talk to Nihonjoe 05:07, 22 March 2016 (UTC)

I know very little about the "halfwidth vs. fullwidth" issue, but if we decide that only one set should be used within ISFDB, then I think we ought to:

update Help, and
update the software to automatically convert the "wrong" version to the "right" version at data entry time.

Ahasuerus 20:15, 22 March 2016 (UTC)

Basically, halfwidth is single byte, and fullwidth is double byte. See this article. I think the software could handle the auto-conversion easily enough since they are different unicode characters. ···日本穣 · 投稿 · Talk to Nihonjoe 21:38, 22 March 2016 (UTC)

The ISFDB software supports substitution pairs -- "if the editor entered X, replace it with Y" -- and we can easily add more pairs once they have been identified. Ahasuerus 22:42, 22 March 2016 (UTC)

P.S. If you want to create a new Feature Request, it will ensure that this functionality is not forgotten. I am kind of swamped at the moment... Ahasuerus 23:42, 22 March 2016 (UTC)

Done. ···日本穣 · 投稿 · Talk to Nihonjoe 00:19, 23 March 2016 (UTC)

Format and book size in the pub series data

I use to add the information about book size and format to the pub series data, e.g. here or here or (more complex) here. In my opinion this is a good place for books collected in a pub series, especially when those data are uniform for all books of the series (it's more often than not); exceptions may be noticed on pub level. Also, I think it's nice to have an overview of all interesting pub series data at one place. Not all of the moderators agree stating those data are not pertinent here because they are pub specific. Your opinion will be appreciated. Thank you! Boskar 06:56, 22 March 2016 (UTC)

I completely agree.Hauck 10:19, 22 March 2016 (UTC)

The format is visibly displayed right there for each publication. The publication date is right there as well. Why provide duplicate information? Let's examine one of the series to which you've linked:

SF for Science Fiction. (Who needs to be told this?)

Publication period: 2005 - 2006. (The series is displayed chronologically, so that's obvious. Although in this case, it should be 2004-2006.)

Number of publications: 6. (Counting does that.)

Format: paperback. (Yep. There it is for each publication.)

Book size: 12.0 x 19.0 cm. (New data. Fine by me.)

Advisor: Michael Nagula. (New data. Nice to know and a welcome addition.)

2 out of 6 items add new data. Mhhutchins|talk 17:11, 22 March 2016 (UTC)

As a general rule I agree that the Note field shouldn't duplicate the data that is readily available elsewhere. However, I can think of two caveats.

First, our data is not guaranteed to be complete, so stating that a given publication series contained only 6 books provides additional information.

Second, there are cases where our data is complete, but it's so diffuse that summarizing it in the Note field may be useful. For example, Ace Double includes dozens of pubs published over a period of many years, so it would be nice if the Note field stated the total number of publications and the period when they were published. It can be even more useful when some pubs in the series are undated, making it hard to determine what the date range was. Ahasuerus 19:48, 22 March 2016 (UTC)

I too have added some pub format information to pub series from time to time. For some examples, see ハヤカワ文庫・SF and ハヤカワ文庫・JA where I explain "Bunko" which is a Japanese publishing format that may not be familiar to western readers (and we currently do not have a format selection for that so I have picked the closest "pb"). I believe this is useful because people entering the pub records in the series may be confused by the format (before I cleaned up the records many had all sorts of different formats recorded). Uzume 15:21, 23 March 2016 (UTC)

That's the purpose of the Note field. I'm not saying it shouldn't be used for clarification and explanation. I'm saying it shouldn't be used for duplication. Mhhutchins|talk 16:35, 23 March 2016 (UTC)

I have no argument here. I was just adding another data point for reference (hopefully that is useful). Uzume 01:05, 24 March 2016 (UTC)

I agree with Ahasuerus. Furthermore, the information of the publication period is also helpful to indicate if a pub series is closed or still running and if the ISFBB is complete for a pub series, especially if the ISFDB doesn't contain all volumes of a series. What if the first and/or final volumes of a pub series are missing in the database? And what about very big pub series as Heyne Science Fiction & Fantasy? In this case it will be necessary to scroll down very slowly to get the information (not to say about counting the records). As I wrote before, I think it's nice to have a quick overview on pub series level whithout clicking through or scrolling down the records. Boskar 01:38, 23 March 2016 (UTC)

"Overview" yes, I agree. No one is disputing that. But you shouldn't duplicate data that's apparent just by looking at the publications in the series. Stating that the series is complete or incomplete is fine, but that's not what you've done in the notes of these series you've linked. All I've been saying all along is that the information should be series-specific and shouldn't duplicate data that is clearly displayed in the listing. No one (me specifically) is saying that you can't update the series with pertinent data. Mhhutchins|talk 02:06, 23 March 2016 (UTC)

My comments to your examples from 17:11, 22 March 2016 (UTC). For me, 4 out of 6 are necessary data:

Publication period... (The series is displayed chronologically...) - Yes, but what if the series data are not complete in the ISFDB? Maybe some series volumes are missing (at the end of the series, or even at the start if the series is unnumbered?). The Publication period also gives the information if a series has been already closed or is still running.

Number of publications: 6. (Counting does that.) - This is true only in case the series data are complete in the ISFDB because 'Number of publications' means 'number of series volumes released' not 'number of volumes available in the ISFDB'. Sometimes some series numbers stay unreleased. I also know about a pub series with 6 volumes but only 5 volumes are genre-specific (this may also be noticed).

You are right about the format (except: sometimes format 'dos' is used, unclear if paperback or hardcover). On the other hand, sometimes it's nice to add some information to the format: e.g. here.

It's okay for me whatever you will accept or not accept in the commment field (no further discussion from my side). Boskar 17:55, 24 March 2016 (UTC)

"dos", as explained here, can only be used for softcover books, that means either "pb" or "tp". If books are "dos" then it's OK to give the dimensions. Also, there is no issue about noting that the ISFDB listing is incomplete. If it is incomplete, then feel free note the number of volumes and the years of publication if that data is certain. Again, I'm talking about duplication of data, not clarification of data. Mhhutchins|talk 18:15, 24 March 2016 (UTC)

Biblioteka by Zoran Živković

After adding a portuguese edition of "Biblioteka" by Zoran Živković, and changed the title record to the original serbian name, i was getting ready to add the 2003 World Fantasy Award for best novella, when i realize a contradiction. This book consists in six individual short stories by Zoran Živković , only conected by the theme - books. So, this title was naturally entered as a collection. The contradiction was, how a collection can be awarded with the prize for best novella, and when the same award as a category for best collection. Then i found this entry, that is categorized as shortfiction but has no publication, and already have the award atached to it. And i notice that this author doesn´t have a text named " The Library" (english title), "The Library" is just the title of the collection of texts, and none of those short stories is named "The Library". I just finished to read this book and althoug every short stories could be read individualy without any precise order, they all have a common narrative theme that glues them together. That´s why, i think, it wons the best novela award and not the collection one. So my question is: how to deal with this entry? Should it be a collection with the World Fantasy Award for best novella atached to it? Or a novella with short stories as content (i don't know if this is possible)? Wolland 00:49, 24 March 2016 (UTC)

We have no such things as a novella publication type (and thus our novella title type is not considered a "container" title type) so your last sentence/suggestion cannot be done (if it makes sense at all). Uzume 01:39, 24 March 2016 (UTC)

We don't recognize award categories as types of publications nor do they determine how we classify a work. An award for best novel can go to a work which is less than 40,000 words, or an award for best long fiction can go to a work we classify as a novel. In most cases, our classification is based on word length and our typing of a publication is based on standards that aren't necessarily the same as the entity presenting the award. In this case, the World Fantasy Award was given to the work as a whole which we had typed as COLLECTION. So I reassigned the award to that title and not to a false record for SHORTFICTION, for which there were no publication records. Mhhutchins|talk 17:18, 24 March 2016 (UTC)

Ok, Thanks. Wolland 18:58, 24 March 2016 (UTC)

2016-03-23 -- server downtime

The server will be unavailable between 9pm and 9:05pm server (Eastern US/Canada Daylight Time.) The nightly cleanup reports will be rerun starting at 9:05pm. Ahasuerus 00:44, 24 March 2016 (UTC)

Everything should be back up. Ahasuerus 01:04, 24 March 2016 (UTC)

Either a whole lot of things got cleaned up or some reports are missing: http://www.isfdb.org/cgi-bin/edit/cleanup.cgi ...OK, it seems they are just slow—my bad. Uzume 01:07, 24 March 2016 (UTC)

No worries, they just take a while to run. There are 122 nightly cleanup reports plus a number of statistical reports than also get rebuilt nightly. Ahasuerus 01:19, 24 March 2016 (UTC)

I am probably just used to the nightly reports running and they just being updated (replaced as they are regenerated) not totally wiped out and regenerated from scratch. Uzume 01:33, 24 March 2016 (UTC)

Changes to the "Latin/non-Latin" cleanup reports

These two reports have been redesigned and corrected based on editor feedback. Each one has been split into two. The resulting 4 reports are listed below:

Publishers with Latin Names and Non-Latin Titles
Publishers with non-Latin Names without Transliterated Names
Publication Series with Latin Names and Non-Latin Titles
Publication Series with non-Latin Names without Transliterated Names

Moderators can mark publishers listed in reports 1 and 3 as "ignored". Each publisher listed in report 1 has a link to a new Web page which shows which non-Latin titles triggered the exception. The logic responsible for generating reports 2 and 4 has been changed to find more non-Latin names. Ahasuerus 01:30, 24 March 2016 (UTC)

The (moderator-only) Latin/non-Latin Legal Names report has been split into two as well. Ahasuerus 18:13, 24 March 2016 (UTC)

P86343

After doing some research, I have determined pub record Etyka technologii i technologija etiki seems to be very messed up. I originally found it by looking at publisher Abakan which appears on cleanup report 99. This appears to be a (messed up) reference to the published works referred to by this: https://fantlab.ru/edition101892 My Russian is not that great but FantLab appears to record a single published work, published by three different publishers in 1993. FantLab records a scanned copy of the title page of one of the publications which Google Books has a record for and includes the ISBN 5-86199-002-6 (and also mentions it is only 92 pages long). I believe the current title of our publication record is actually in Polish and refers to part of the publication's title and one of two essays included in Russian: Etyka technologii i technologia etyki. That essay in the original Polish was included in the publication Dialogi and why I believe the non-fiction title record that corresponds with this messed up pub record was made a variant of our non-fiction title Dialogi (but I believe the title and contents of these publications are different enough that I do not consider it a translation of the non-fiction title though one of the essays is obviously a translation in the Russian work in question). I do not believe we currently have a record of the other included essay: Модель культуры (original Polish: 1968 "Wprowadzenie w metakrytyke"). Incidentally, "Abakan", the publisher listed in our pub record (which brought me into this), seems to actually be the location Abakan, which if I am reading FantLab correctly is the location of Центавр (Centaurus) one of the three publishers of this work. In short, this might take me a few submission to untangle and if anyone has a better interpretation (any one know Russian well?) please feel free to chime in. Thank you. Uzume 02:07, 25 March 2016 (UTC)

I'll take a look tomorrow. Ahasuerus 03:42, 25 March 2016 (UTC)

I think I have now straightened this out but let me know if you see anything amiss. I am still concerned about the translation credit for Этика технологии и технология этики Clearly this was translated by О. Салнит (O. Saône) in 2005, however, I wonder if the 1993 publication is a different translation (based on the OCLC: 751194998). Thanks. Uzume 14:25, 25 March 2016 (UTC)

I believe your analysis is correct, but the way the data is currently presented doesn't reflect it. As per FantLab, this was a single 92-page book co-published by 3 Russian publishers, but we show 2 editions, one by Центавр (Centaurus) and one by Бегемот. I suggest we delete the former and add the other two publishers to the latter. Ahasuerus 16:13, 25 March 2016 (UTC)

You read that as some sort of co-published item? I have serious doubts about that. FantLab often lists "editions" with multiple publishers but I doubt it represents a single multiple co-publisher publication (notice it also mentions multiple locations, how does that work?). Other examples are: https://fantlab.ru/edition63362 (notice the two different ISBNs one from each publisher). That is why I read that as three publications of the work by three different publishers (with mostly the same content and thus the same "edition" as per FantLab's definition of "edition" which we do not really have). In our system how do we add multiple publishers to a single pub record? Uzume 22:37, 25 March 2016 (UTC)

According to FantLab, the Russian publishing scene is complicated. There are many "true" collaborations, e.g. Terra Fantastica [sic], a publisher based in Saint Petersburg, mostly collaborates with АСТ ("AST"), ЭКСМО ("EKSMO") and other major publishers based in Moscow. On the other hand, АСТ owns a number of imprints like this one which are technically independent companies, but their books are always published as by "АСТ and [imprint]". These companies are sometimes registered in small towns far away from Moscow (for tax reasons?), e.g. see the address listed for Люкс.

As far as the number of ISBNs listed by FantLab per "edition" goes, it would appear that books co-published in the 1990s had one ISBN per publisher because each publisher was assigned a separate block of ISBN numbers and couldn't share it with other publishers. For example, АСТ's 1998 edition of "Ночной Дозор" was technically co-published by АСТ and its previously mentioned imprint Люкс, so it had two ISBNs, 5-237-01511-5 and 5-9660-0229-0. The former was owned by АСТ and the latter by Люкс. Curiously, when the book was reprinted in 2000, it was given only one ISBN, 5-17-001090-7, owned by АСТ. However, at least some true co-published books like this one had multiple ISBNs as late as 2012. Perhaps the rules were changed for imprints only at some point between 1998 and 2000? [Edit: Then again, this book "co-published" by АСТ and two of its imprints in 2007 had three ISBNs.]

Be that as it may, I don't think the presence of multiple ISBNs indicates that there are three versions of Lem's book. It just means that the copyright page lists all three of them. Unfortunately, out software doesn't support multiple ISBNs per publication record, so there is no easy way of entering multi-ISBNs books. As per Help: "If a publication has more than one number, then enter the one that seems most reasonable in the ISBN field but then also add a comment to the notes field about the various numbers and where they are located in the publication." Ahasuerus 00:05, 26 March 2016 (UTC)

That may well be true but I do not see this as much different from multiple printings of a single edition. We (attempt) to record each of those as separate pub records (except in some special cases like SFBC editions). These are just different printings by different publishers. Why would we not handle them as separate pub records? Uzume 02:39, 26 March 2016 (UTC)

I guess I don't think of them as separate printings by different publishers. It's a single publication that happens to have multiple ISBNs and multiple publishers, just like there are publications with multiple prices (UK/US/Canada/etc.) We don't create multiple publication records for the latter and I don't think we should create them for the former. BTW, this is apparently more common that we realized -- see the scan of a Polish multi-ISBN book posted on this Goodreads page. Ahasuerus 03:28, 26 March 2016 (UTC)

And even if we wanted to special case this type of things somehow, how would you propose we assign multiple publishers to a single pub records? Are we going to make special publisher records where this type of collaboration occurs (perhaps looking somewhat like an imprint). Or are you proposing to extend the software to allow multiple publishers per pub records? Uzume 02:39, 26 March 2016 (UTC)

For now, we will probably have to enter the three publishers as one composite publisher similar to the way we handle imprints -- which, as per the discussion above, some of them are. In the long run we will need to revisit the issue of publishers and imprints. As I wrote on my Talk page a few days ago:

I guess the long term solution will be to add support for multiple publishers per publication just like we support multiple authors per pub/title and multiple Web pages per author/title/etc. [...] Ideally, our software would let us record infinitely nested publisher hierarchies just like it lets us record infinitely nested series hierarchies now. Unfortunately, publishers are more complex than series -- imprints become separate publishers, publishers become imprints, etc -- which makes it harder to model in the software.

As far as multiple ISBNs go, we have an FR to Add a new field to pub records for corrected ISBNs, an FR to Add support for external identifiers and an (undocumented?) request to create a separate field for catalog IDs so that we could more easily capture them and ISBNs at the same time. Now that we know that multiple ISBNs per pub are not unknown, I am beginning to wonder if the best way to handle this tangled web may be to change the "Catalog ID/ISBN" field to a repeatable group of two fields: "Identifier Type" and "Identifier". The former will be a drop-down list of identifier types like "ISBN", "Catalog ID", "ASIN", "OCLC", "LCCN", etc. The latter will be a simple data entry field. Ahasuerus 03:28, 26 March 2016 (UTC)

NONFICTION record not displayed in table of contents if the pub contains additional titles

NONFICTION publications which also contain other titles (e.g. a foreword) only display the other titles in the contents, but not the NONFICITON title itself. Example: this one. The list of contents looks incomplete because you see the page number and entry for the "Introduction" record, but nothing else. This deviates from the (correct) way NOVELs with additional titles are displayed (see this example). Looks like a bug to me. Jens Hitspacebar 19:57, 26 March 2016 (UTC)

Not really. Just as publications which are typed as COLLECTION, ANTHOLOGY, MAGAZINE, FANZINE, CHAPBOOK, or OMNIBUS, don't display their title reference record, a publication typed as NONFICTION doesn't display its title either. The one type for which there is an exception is NOVEL. And that title is only displayed when there are other content records. Mhhutchins|talk 21:26, 26 March 2016 (UTC)

I see a major difference between NONFICTION and COLLECTION/ANTHOLOGY/MAGAZINE/FANZINE/CHAPBOOK/OMNIBUS: the latter ones are all containers for other titles, therefore it indeed doesn't make sense to list them themselves in the table of contents. NONFICTION however can be a work itself, like the example I linked above. An occasional user with no expert knowledge about how the ISFDB works who comes across this publication record will certainly scratch his head and ask himself why there's only an "Introduction" on page 13 and nothing else in the list of contents. Many questions will arise which can not be answered without digging deeper into how the ISFDB works: How many pages does the "Introduction" have? Almost 500? On which page does "Trillion Year Spree: The History of Science Fiction" start? Or are the data just incomplete? Therefore displaying the NONFICTION record in a case like this makes sense. I'm sure that's what an occasional user would expect intuitively. However, if NONFICTION shall be considered a container then an ESSAY title record "Trillion Year Spree: The History of Science Fiction" should be added to the publication record (like it was done for The Annotated Supernatural Horror in Literature). To sum it up: if there is more than the NONFICTION title itself in a NONFICTION publication, the software should either display the NONFICTION record as well in the list of contents, or the editors should always add an ESSAY record of the same name. Otherwise the list of contents looks incomplete and wrong. Jens Hitspacebar 23:58, 26 March 2016 (UTC)

NONFICTION can be used for both 1) a single book-length work of nonfiction, or 2) a collection of individual essay-length works of nonfiction (i.e. a container). The only way I can see to handle the display of the title reference in the first type is to create a different type of publication. I don't know how the software can determine the difference otherwise. The time and effort required to create such a substantial software change simply wouldn't be very efficient if the only reason is to display a title reference in a book typed as NONFICTION. I would be against the adding of an ESSAY record for a book-length work of non-fiction, just so they the display wouldn't look "wrong" (a subjective opinion at best). Doing so would cause the same work to appear twice on the author's summary page, first under the Nonfiction category as a book, and then under the Essays category as an essay. BTW, there is no content in The Annotated Supernatural Horror in Literature which is titled "The Annotated Supernatural Horror in Literature". Those contents are individual essays. The Lovecraft essay has been published as a contained work in many different publications, thus typed as ESSAY, not NONFICTION. Mhhutchins|talk 00:18, 27 March 2016 (UTC)

First, as for the Lovecraft title, this is a better example: same title for ESSAY and NONFICTION. Jens Hitspacebar 01:14, 27 March 2016 (UTC)

That's a relatively rare case: a standalone book publication of an ESSAY. It's not actually book-length, and you don't see a visible NONFICTION title reference record in its list of contents. You only see the contained essays. Mhhutchins|talk 02:44, 27 March 2016 (UTC)

But I agree with you regarding ESSAY records: it is rather not desirable (because they would appear twice). However, as for the "wrong" list of contents opinion being a "subjective opinion at best", I disagree. Why is that subjective? Jens Hitspacebar 01:14, 27 March 2016 (UTC)

You originally said it "looks incomplete and wrong", not that it is wrong. That makes it a subjective opinion. How something looks to one person may be different from how it looks to another. Case in point, it doesn't "look" wrong to me. Mhhutchins|talk 02:44, 27 March 2016 (UTC)

I guess there's probably a misunderstanding here regarding the word "look" because as a non-native speaker I might not get all the nuances of the English language. When I wrote "looks incomplete" I didn't mean "could be" or "seems to be", but something like "is displayed". So I meant it is wrong in the first place. But that's nitpicking. As for the "opinion": I've given serveral reasons for why the list of contents is wrong. You have only said you think it's not wrong, but not why. But let's drop that point here and get back to the topic itself below. Jens Hitspacebar 09:49, 27 March 2016 (UTC)

There's a list of contents which doesn't display all contents (though the data are all there internally). In a book this would be a printing error. That's objectively counter-intuitive. But I see your point regarding how the software should distinguish a NONFICTION publication which is a work itself from a NONFICTION which is a collection of other essays only. Tricky. Idea: if the publication contains more than itself as a title record show a check-box (or yes/no select-box) named "Show in list of contents" or "Title is contained in the publication alongside other titles ". If ticked (or set to "yes"), the NONFICTION record is displayed, otherwise not. Other idea: if the title's "Page" field contains a value, show the title record, otherwise not (if blank because neither page number nor title order are known than the pipe used in the pages field for sorting could be expanded with a new value, for example "|show"). Jens Hitspacebar 01:14, 27 March 2016 (UTC)

Again, you're talking about a software change and something which I'm unable to determine could be implemented. I'll leave it to our software writer to determine if such a change is possible. But it's my opinion that such a change wouldn't be worth all of the effort it would take to implement. If you believe the title reference should be visible in NONFICTION records, why not just make title references visible in all records? That would appear to be easier to implement. Perhaps your check box method is possible when creating new records, but how would you update the thousands of records already in the database? We would have to go through every publication typed as NONFICTION in the database to determine to which of the two categories I described above it should be assigned. That's not as easy as it sounds. There are hundreds of records for which we don't have enough information about their contents to know how to categorize them. For example, many books published by academic publishers are essay collections, but the contents haven't been added to the record. How could we know if it's a book-length work or a collection of essays by various authors? That would take a tremendous amount of research, looking for secondary sources, and adding the essay contents. Who's going to do that?Mhhutchins|talk 02:44, 27 March 2016 (UTC)

As for your last point: that's not a case I'm talking about. If a NONFICTION has no content records nothing has to be researched and nobody has to do anything. I'm only talking about publications were at least one additional title record is entered. Jens Hitspacebar 09:49, 27 March 2016 (UTC)

[unindent] The primary mission of the ISFDB is to catalog speculative fiction, emphasis on "fiction". That includes novels, short stories, poems, etc. It takes enough effort to maintain our primary mission, and we aren't "caught up" there by a long shot. There are, of course, many other things that we could do, but everything else is secondary. So there are certainly some visitors who wish that we would:

Have links from books that have been made as movies;
Tell which stories have been adapted as graphic novels;
List every piece of art in a book with the page number, instead of a generic "Internal Art" record;
Know which non-fiction books are collections of essays, and which are structured as books;
For non-fiction "books", know the titles of each chapter in the book;
etc.

For each of these items, I suspect there are some editors that would like to have that information. But we can't add major new types of data unless we have buy-in from a lot of our existing editors. In the last couple of years, we've made major steps towards including non-English works, and to including ebooks. Both of those are projects that are far from complete, but both are projects that several editors are willing to work on. I may be wrong, but I seriously doubt we would get the same co-operation on re-visiting all of the non-fiction books we have to try to distinguish those which are "books" from those which are collections of essays. Even if the software were changed so we could distinguish those 2 cases, it's hard to imagine that we would ever end up doing a creditable job of correctly assigning that flag. Chavey 08:04, 27 March 2016 (UTC)

I understand that. Of course there are a lot of other desirable things, and the topic we're talking here is certainly not a high priority at all. But talking about the priority is something different than the validity of a point. So far the reasons given against my point are technical/work load ones: that the software change and corrective edits to be done afterwards could be too big (and obviously doesn't seem to have a high priority). That's a valid point, no objection. As for the point "incomplete list of contents" itself, leaving technical issues aside and only viewed from a user's perspective, I've given enough reasons why the list of contents is incomplete. From my point of view: case closed. Jens Hitspacebar 09:49, 27 March 2016 (UTC)

Wildcards when using "is exactly" in Advanced Search

As per Bug Report 607, Advanced Search has been changed to allow wildcards when using "is exactly". Ahasuerus 20:35, 29 March 2016 (UTC)