ISFDB:Community Portal/Archive/Archive38

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

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

---

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

---

Expanded archive listing

Archives of the community portal for October - December 2015

Nominating Albinoflea for moderator

I hereby nominate Albinoflea (talk • contribs) to be a moderator and he has accepted. He has been an editor on the ISFDB for more than five years, and has grown proficient in every area of the database: creating new records, updating records, varianting, and merging. He also has good communication skills and the right mindset for being a moderator. As such, I believe he is extremely qualified for the position, and he'll be a great asset to the moderating team.

Support

1. Support, as nominator. Mhhutchins|talk 04:13, 1 October 2015 (UTC)
2. Support. Good communication skills, good working knowledge of the software/database. Ahasuerus 04:22, 1 October 2015 (UTC)
3. Support. What he does, he usually does right. I'm all in favor. Stonecreek 13:12, 1 October 2015 (UTC)
4. Support. The few submissions I've seen from him looked good. I trust Michael's estimation of his edits, and looking at his talkpage shows good communication skills. --Willem 18:30, 1 October 2015 (UTC)
5. Support. For all the reasons stated above. PeteYoung 00:24, 2 October 2015 (UTC)
6. Support. Despite the low number of contributions over the five years, he seems to know his stuff. I trust him. ···日本穣 · 投稿 · Talk to Nihonjoe 05:00, 3 October 2015 (UTC)
7. Support. Sorry to be late to the party. No reservations. I haven't had to question a submission in years, and his communication skills are excellent. --MartyD 00:38, 6 October 2015 (UTC)

Oppose

Comments/Neutral

1. Neutral A number of contributions (less than 1700) a bit low overall for a moderator and denoting a sporadic activity (five years as an editor). Hauck 12:45, 1 October 2015 (UTC)

Outcome

The nomination was successful. The moderator flag has been set on the account. Congratulations! Ahasuerus 20:16, 6 October 2015 (UTC)

2015-10-01 -- Brief database outage at 5pm server time

There will be a brief database outage between 5pm and 5:05pm server (US Central) time. Ahasuerus 21:48, 1 October 2015 (UTC)

Updating the "Pub Binding/Format" help documentation

Since there are almost 700 records in the database for MAGAZINE-typed publications entered as "tp", I have updated the help documentation to include it as an option for print magazines. The addition is:

• tp - trade paperback magazines, usually perfect-bound, i.e. periodical publications (often POD) which otherwise would qualify as trade paperbacks (see "tp" in the Print books section)

If there are suggestions for further clarification of the documentation, please let me know. Mhhutchins|talk 19:35, 2 October 2015 (UTC)

I see you made a few other changes at the same time to improve nearby sections, and I like them all. I especially appreciate it when someone shows they know the difference between "i.e." and "e.g." :-) Chavey 14:19, 5 October 2015 (UTC)

Extra long synopses

Some of our synopses are quite long, approaching 3,000 characters. For example, consider Borrowed Time. The synopsis field accounts for 70%+ of the page, which seems excessive. Should we institute a policy requiring anything beyond the first N characters to be hidden behind {{BREAK}} now that the functionality is available? If we decide to do it, I can whip up a cleanup report identifying the offenders.

For reference purposes, we have 13 titles with 2,000+ character synopses and 299 titles with 1,000+ character synopses. The total number of titles with synopses is 9,962. Ahasuerus 15:40, 3 October 2015 (UTC)

I believe we need to limit the synopsis to 1000 characters or less. That way we wouldn't have to deal with a break. I can't imagine that any work would need more than 1000 characters to synopsize. Mhhutchins|talk 19:06, 3 October 2015 (UTC)

It seems like a reasonable policy when entering home-grown synopses, but what should we do when dealing with publisher-provided ones? It may require careful editing and lots of ellipses, which can make using BREAK an attractive alternative, especially since BREAK is already supported in the Synopsis field. Ahasuerus 02:38, 4 October 2015 (UTC)

In my experience, long publisher synopses can usually be abbreviated by selectively excluding some introductory text or else things such as a final paragraph. There's usually stuff that goes into too much detail on plot, and is unnecessary to just getting a sense as to what the book is about. IMHO, any book that deserves more that Mike's suggested 1000 characters deserves, instead, to have a Wikipedia page that we link to. If it's not significant enough for Wikipedia, it's not significant enough for a lengthy extract here. Chavey 15:01, 5 October 2015 (UTC)

Two David Gerrolds?

Based on circumstantial evidence, it would appear that the author of the novel Jacob is not the same person as "our" David Gerrold. Would anyone happen to have a way to confirm it? Ahasuerus 02:34, 4 October 2015 (UTC)

Yes, he's "our" David Gerrold. Look on the back of the book via the Amazon listing. Mhhutchins|talk 03:36, 4 October 2015 (UTC)

Just added a new collection from the same publisher. As there are only two works from this publisher, he could be self-publishing these new works. Both have "DG Media Banner Edition" on the back cover. Mhhutchins|talk 03:53, 4 October 2015 (UTC)

Nice, thanks! Ahasuerus 04:39, 4 October 2015 (UTC)

Locus dates in square brackets?

A great many Locus online site book entries have a second date in square brackets after the first date listing; I'm guessing they indicate an alternative edition or similar, but can't find anything about them elsewhere on the site - does anyone know what the intended reason for them is? Thanks, Astrodan 13:08, 4 October 2015 (UTC)

On the printed versions of the indexes (I've grabbed this one), the date in brackets is given as being [Date First Seen]. I suppose it's the same meaning online. Hauck 13:38, 4 October 2015 (UTC)

Based on my experience with their Web site, your interpretation is correct. Sometimes they get books before the official publication date and sometimes (much) later. Ahasuerus 16:50, 4 October 2015 (UTC)

Thanks, Hauck Astrodan 13:53, 4 October 2015 (UTC)

Triplanetary (1934 serial version)

I noticed that one of my primary verified publications (Triplanetary) has recently been edited. The intent appears to have been to separate out the serialized and novel versions of Triplanetary. While I can agree with the intent, I have concerns with the implementation:

• Title Records: I don't see the need to disambiguate the various title records to Triplanetary (1934 serial version). Disambiguating title records is usually used only for common titles (Introduction, etc.). For cases like this, we normally rely on the notes alone. I believe the title records should be restored to "Triplanetary". At the most, the parent record could be disambiguated and the variants should retain there as-published titles.
• Publication Records: Even if we use the title record disambiguation, the publication titles should not have been updated to add the "(1934 serial version)". The publication titles should match the publication title page per our standards.

I'm surprised that such a major change would have been made to primary verified publications without any notice. While the other two primary verifiers are no longer active, that should have entailed a note at the moderator noticeboard and I should have been notified. -- JLaTondre (talk) 16:37, 4 October 2015 (UTC)

I made two submissions in the early hours of 10/3: 1) to change the date of the title record to be consistent with the rule of first book publication of a serial, and 2) to variant the title record of a Fixer-submitted record to the canonical author. I made no changes to your verified record. These two changes were made because the title showed up on a cleanup report. Looking over the list of accepted submissions for late 10/2 (which caused them to show up on the following day's reports), Marc Kupper made more than 30 submissions affecting both title records and publication records, including yours. I can see why the two works should be separated, and the disambiguation seems to be the most effective way to keep them separate. But I agree that the publication's title fields should not have been changed. And you should have been notified. I'll leave a message on Marc's page to ask him to join the discussion. Mhhutchins|talk 17:05, 4 October 2015 (UTC)

It's been quite awhile without a response from Marc and he's been active. I've gone ahead and restored the publication records [removing the "(1934 serial version)"] so they match the publications as per our standards. I still believe the title record disambiguation is unnecessary. It is no different than a case where an author has used the same title for two different stories. However, I don't feel strong enough about it that I would pursue debating it. -- JLaTondre (talk) 20:29, 16 October 2015 (UTC)

I agree that the title fields of the publication records should not have been disambiguated. Because of the mismatch in the title fields of the publication and title records, this will show up on the cleanup report which finds mismatches (once novels have been added to it), but at least now we have the option to ignore such discrepancies. Mhhutchins|talk 20:36, 16 October 2015 (UTC)

Alerting all editors: single cover art with multiple credits

Since the software change which creates multiple cover art records when an editor uses the "Add Artist" button when creating a publication record, it is important to only use that button if there are two covers for which there are separate credits. Do not use that button when there are multiple artists credited for a single cover. You should only enter one credit at the time of the publication record's creation, and then once it is moderated, you have to go back and update the one cover art record to add the other credits. Without this workaround we are creating hundreds of false records, both publication records and cover art records. It is much harder to fix these after their creation than it would be to avoid them in the first place. Unless there are volunteers who are willing to help clearing the 2000+ records on this clean-up report.

I personally wish the software would be changed so that the default of using the "Add Artist" button would create a single record crediting multiple artists, Mhhutchins|talk 17:34, 4 October 2015 (UTC)

Yes, it's possible to implement. However, COVERART records have a number of issues associated with them, e.g. Bug 155 (Shared COVERART titles not handled consistently), and I hope that we can implement a single major change which will address all of the issues in one fell swoop rather than applying multiple partial band-aids. As discussed earlier:

• It would appear that the most straightforward solution would be to convert the current multiply occurring "Artist" field to a multiply occurring "Cover Art" group of fields. Each "Cover Art" occurrence would then support multiply occurring "Artist" fields. It would be similar to the way the Content section works: it supports multiple "Title" groups and each group supports multiple "Author" fields. Ahasuerus 19:05, 4 October 2015 (UTC)

and that the record would appear on each artist's summary page as "Cover: XXXX [with ArtistB]". Ahasuerus, is that possible? Mhhutchins|talk 17:34, 4 October 2015 (UTC)

I am not sure I am reading the second question correctly. The way the "Cover Art" section of Summary pages works is similar to what you seem to be describing. For example, here is a section of Leo Dillon's Summary page:

• Cover: The Odyssey: The Story of Odysseus (1963) with Diane Dillon
• Cover: The Complete Short Stories of Mark Twain (1964) with Diane Dillon

What kind of changes would you like to see? Ahasuerus 19:05, 4 October 2015 (UTC)

If I understood this problem correctly then this is all news to me, and the Help is wrong (and incomplete) then: "Add Artist. If the cover art is credited to more than one artist, this button will create a second artist field." Also, the "Add artist" button label should probably be renamed to "Add Cover", at least for the time being until the software has been changed, because I think this label is less prone to be misunderstood. Jens Hitspacebar 20:32, 4 October 2015 (UTC)

The Help page may not have been updated when the software change was made that created separate cover records (as opposed to separate cover artists). And yes, you're correct. Instead of being labeled "Add Artist", it should be "Add Cover" since that's exactly what it does. It doesn't add an artist to the cover record. Mhhutchins|talk 21:32, 4 October 2015 (UTC)

The reason the Dillons' pages look that way is because it took me the better part of a day to fix all of their records about a year ago. And I'm going back to check it every month or so to find new errors to correct. Those records are the way they should be, not the way they would exist if I hadn't fixed them. Mhhutchins|talk 21:32, 4 October 2015 (UTC)

Understood, but I am afraid I am still not sure what kind of change to the way the Summary page behaves you would like to see. Could you please provide an example of the data appearing one way while you would like it to appear another way? Ahasuerus 23:39, 4 October 2015 (UTC)

Look at any recent publication record which had multiple artists credited for a single cover. For example, this publication record was created today. There is one cover credited to two artists, but there are two cover art records each attributed to each artist. There should be one cover art record credited to two artists. If you look at one of the artist's summary page there's no indication that the cover was a collaboration, as in " [with Shutterstock]". If you click on the cover art record, you have no idea that it was a collaboration. Of the 2300+ records on the clean-up report, I'd guess that 90% of them are cases like this, instead of publications with two covers. Tomorrow morning, this publication record will show up on the cleanup report. Mhhutchins|talk 00:43, 5 October 2015 (UTC)

True enough, but that's a data entry problem, not a display problem, which was how I originally interpreted your second question. Unfortunately, once the software has created two COVERART records, the damage has been done and it can't be undone by changing the way the Summary page displays things. Ahasuerus 01:30, 5 October 2015 (UTC)

And that's the purpose of my original post. To ask editors to not use the "Add Artist" button for single covers, because the software acts like you want it to create two covers. So it's not a "data entry problem". The editors are doing exactly as they are being told to do: add a new artist. They're just now aware of what the software does with the data that is entered. They don't realize that the software is creating multiple cover art records. Mhhutchins|talk 01:38, 5 October 2015 (UTC)

Sorry, I didn't mean to imply that it was the editors' fault. I guess I should have said something like a "data capture problem", as opposed to a display problem. Ahasuerus 02:30, 5 October 2015 (UTC)

What we need to do is change the way the data is captured and stored in the database, not change the way it is displayed. The latter would only make things worse by incorrectly displaying pubs with 2 covers like An Earth Gone Mad / The Rebellious Stars. I'll see what I can do in the next few days. Ahasuerus 01:30, 5 October 2015 (UTC)

That's exactly what I'm asking. But until the software is changed, the least we can do is ask editors to minimize the damage being done now. I doubt many moderators will be working on that cleanup report to fix the thousands of bad records in the database. Thanks. Mhhutchins|talk 01:38, 5 October 2015 (UTC)

It seems it might be helpful to have a cleanup report that warned us about all pubs that listed as having two covers, but aren't in dos-a-dos format. Chavey 14:24, 5 October 2015 (UTC)

That was silly. I clearly don't know my cleanup reports as well as I should. Chavey 03:26, 6 October 2015 (UTC)

We are up to 95 reports -- there are times when I have to check the code to see what they do :-) Ahasuerus 04:00, 6 October 2015 (UTC)

A question, though: Does that clean-up report auto-skip books that are listed as "dos" type? Chavey 03:26, 6 October 2015 (UTC)

I see it does not filter out such books; presumably we have to mark books such as this (a dos currently on that cleanup report) as "Skip". Chavey 03:56, 6 October 2015 (UTC)

That's right. A dos pub has two covers and each cover may have 2+ artists, so I think it would be best to check them manually. Ahasuerus 04:00, 6 October 2015 (UTC)

I went through all dos pubs on the list (well, all those that were named "title 1 / title 2"), and they were all limited to two authors, so I "ignored" all of them. And made some other progress on the cleanup report list. Chavey 23:18, 6 October 2015 (UTC)

Excellent, thanks! Ahasuerus 23:30, 6 October 2015 (UTC)

I hope you meant two "artists" and not "authors". :) Records with two covers by the same artist has to be manipulated to credit him for both covers. This involves changing his name to a temporary one because the system currently doesn't create two cover records when only one artist does both. Mhhutchins|talk 01:45, 7 October 2015 (UTC)

(unindent) Yes, I meant "artists". I did run across one book that had 3 "covers" on the cover, 2 by the same artist, so that was left as it was with 3 covers. (I think I then hit the "ignore" link.) Chavey 15:01, 8 October 2015 (UTC)

For the record, and regarding the very beginning of this discussion : I followed the suggested procedure, and added a second artist credit after moderation, but ended up with two covers here. And this is not the first time this procedure doesn't work (with me, anyway). Linguist 16:14, 8 October 2015 (UTC).

It looks like you updated the publication record and not the cover title record. It's going to take two submissions. On the first submission, remove one of the artist credits. Then you must wait for that submission to be moderated before making the submission updating the cover title record. It can not be sitting in the queue at the time the first submission is moderated. Add the removed artist credit back in the second submission updating the cover title record, not the publication record. Mhhutchins|talk 16:42, 8 October 2015 (UTC)

Ah, right, I get it. I had understood “update the one cover art record” as “update the art cover field in the record”. Thanks for the clarification. Linguist 21:38, 8 October 2015 (UTC).

Size doesn't matter (or does it ?)

Discussion copied from Bill (Bluesman)'s talk page:

Hi Bill. As you might have noticed, I had re-sized this image from 640 to 600 pixels, as regulations seem to imply this should be the norm (if I understood them correctly). Just for the record, and for my own understanding of the sometimes implicit rules of this database, could you enlighten me as to the reason of your revert ? TYIA, Linguist 20:38, 4 October 2015 (UTC).

Simply put, file size. Though the image was reduced in pixels, the file size actually went up [not a lot in this case, about 10kb??]. While we will never run out of pixels, the available storage space for the DB is finite. This peculiar rule was adopted when the DB was quite new and when pixels/file size were more tightly bound to each other. It's sad it hasn't been updated, strange that the warning about the file size doesn't come up until after an upload is attempted. With all the newer programs for manipulating images pixels and kbs have little to do with each other, so no, size [pixels] doesn't really matter. It's like comparing a cubic mile of pure vacuum to a cubic centimeter of neutronium ..... and only taking into account the dimensions. I'll get the usual storm of protest that "Da rules is da rules!!!" .... ah, well .... If you can reduce the size [pixels] of any image without losing the details that matter [prices/catalog #s/artist signatures/etc] AND reduce the file size, go for it, but don't sacrifice the data just for the ephemeral. A particular editor resized several hundred images from another editor but in each case the file size went up by at least 30%, but by golly "Da Rules" were being followed ................. Cheers! --~ Bill, Bluesman 21:37, 4 October 2015 (UTC)

Several thousands, I say ;-) Hauck 05:59, 5 October 2015 (UTC)

Thanks for your answer. I'll try and make the most of it… :o) Linguist 09:48, 5 October 2015 (UTC).

No. No. No. Don't do it. By Bill's rationale, we could upload an image that is 2,000 pixels tall, as long as it was under 150 kb. No, that's wrong. The reason why we limited it to 600 pixels was to claim the fair-use stance and to protect copyrighted material, and that had nothing to do with server capacity. We had to make sure that copyright holders couldn't accuse of hosting files that could be used to create illegal copies. Someone (not me) determined that 600 pixels would be about the limit before our fair-use claim would be questioned. Most of us are staying within that limit, so there's no reason why all of us can't. Mhhutchins|talk 16:41, 5 October 2015 (UTC)

Not correct. The reason for the 150 kb limit is to stay within the fair-use stance. Any image that has 150 kb of data or less can't be used to make a commercially viable copy, regardless of how many pixels there are [10x10 or 1,000,000x1,000,000] the file size determines how much data there is to be used/abused, nothing else. The pixel 'limit' is from at least 15 years ago?? Sadly out of date now with all the newer programs that let one manipulate same. As for below, when the option was still available to restore a deleted image, I checked many that you had resized and M. Hauck's images would run 65-90kb before but were over 125 after 'reducing' them. Quirk of the program?? There was really no point in reducing them at all as they weren't of high enough resolution to make a commercial copy. --~ Bill, Bluesman 23:44, 7 October 2015 (UTC)

And BTW, I have reduced the image size of several hundred files uploaded by both Bluesman and Hauck (maybe even thousands, I didn't keep count), but the size of the file was ALWAYS reduced as well. That's something I shouldn't have had to do, but when I approached both of them about violating the standards, they either refused or ignored my requests. If they felt strongly that the standards should be changed, then they should have brought it before the group for discussion, and not made unilateral decisions to ignore the standards. That's not how a community works. Mhhutchins|talk 16:49, 5 October 2015 (UTC)

Says our expert on community management. Hauck 19:49, 5 October 2015 (UTC)

Says our expert on snide remarks which add nothing to the discussion. Mhhutchins|talk 21:14, 5 October 2015 (UTC)

禅. Linguist 20:46, 5 October 2015 (UTC).

(unindent) Bill and Michael are both right. Hosting extra-large high-resolution images (at one point an editor uploaded a 2MB file!) can cause copyright issues. At the same time, our disk space remains limited, so that's also a concern. We've been OK disk space-wise since the last round of optimizations, but it can become an issue if we are not careful. Ahasuerus 23:36, 5 October 2015 (UTC)

Actually, no. Bill is saying that there should be no consideration for the image size limit as long as we stay within the file size limit. I'm saying we should be considerate of both, each for different reasons: the image size for copyright reasons, and the file size for server space reasons. Mhhutchins|talk 04:12, 6 October 2015 (UTC)

It's NOT the image size, it's the resolution used [ie: the file size] that would constitute copyright infringement. --~ Bill, Bluesman 23:44, 7 October 2015 (UTC)

Also, let me repeat my mantra from years past: the internet is a wonderful tool, but, unfortunately, it doesn't transmit your body language, which can cause all kinds of misunderstandings and lead to unnecessary conflict. Ahasuerus 23:36, 5 October 2015 (UTC)

Some words and their meanings are quite clear, regardless of any unseen body language. And this particular editor has made such remarks consistently, so I don't need to see his body language to understand exactly what he means. There's no possibility of misunderstanding in this case. Mhhutchins|talk 04:12, 6 October 2015 (UTC)

(unindent) I had thought the reason for the 600px limit as a specific number on ISFDB is because we don't have a wikimedia add-on, plugin, or whatever it's called in that universe to auto-scale images. At the time, and possibly the present, we did not have internal expertise to do the level of twiddling needed to install the component. If an image is over 600px then you get a white box on the Image:... pages though can still use the image on publication and author records. Thus 600px became a technical limitation. It also worked out well as a copyright and fair-use limitation. At the time, Amazon had a 500px limit and so was setting a standard in that area. After some discussion we felt it was safe to use 600px. Please see Rules and standards discussions/Archive/Archive05#Image scaling for a discussion back in 2008. Marching forwards, Amazon's limit is now 1000px and Goodreads (owned by Amazon) uses 933px.

The file size grows as the total number of pixels grow at a 4x rate for each doubling of the number of pixels. My 600px images are averaging 48,838 bytes. If we went to 1000 pixels it would be 104,350 bytes per image. --Marc Kupper|talk 08:40, 6 October 2015 (UTC)

When one is scanning. You can't take an existing file, double the 'space' it occupies [pixels in this case] and get 4x the data. All you'd get is a very grainy image, again useless for commercial copying. --~ Bill, Bluesman 23:44, 7 October 2015 (UTC)

Criminal or detective stories

I try to find out if detective or criminal stories are to be included in ISFDB or not and don't get a conclusion. Sherlock Holmes is marked as NONGENRE, but the Black Widowers from Asimov not. Some detective stories are included, others not. The Rules page does neither say yes nor no. As I think more is better I'd prefer to include them all as borders between fiction genres are and will never be clearly defined. IS there an consensus which only was not documented? --Stoecker 16:06, 6 October 2015 (UTC)

The Rules of Acquisition cover it under items 4 and 8. Without any speculative fiction elements, they would only be included if the author is "above the threshold". Unfortunately, "above the threshold" is not an easily quantifiable description and different editors have different opinions. When there is debate, it should be brought here for group consensus. As far as marking them non-genre, that is a relatively new field. If the stories are included because the author is above the threshold and they don't have any speculative elements (which can also be debated as different editors have different thresholds for that as well), they should be marked non-genre. Not all older entries have been updated. -- JLaTondre (talk) 16:15, 6 October 2015 (UTC)

Isaac Asimov is "above the threshold", so his mystery stories should be included in the database. Those without any speculative element should be marked non-genre. Raymond Chandler is not "above the threshold", so only his speculative fiction stories would be eligible for the database. The measurement of "above the threshold" is too nebulous to be documented. As JLaTondre says, if you're uncertain if an author qualifies, you can inquire here on the Community portal. Mhhutchins|talk 17:54, 6 October 2015 (UTC)

ISFDB app for iPhone / Android

Because of my own personal library I've been forced to download and use an Android app on my phone to keep track of what books I own. In my search for just such an app I stumbled across your wonderful database. It has occurred to me that you could expand and fill-in your online database by the creation of your own app. Such an app could assist the users by helping them log and keep track of their own physical libraries on their phone/tablet (as I do). In trade the users could use the app to help isfdb fill in details on the books already here as well as add missing books when the user happened to be trawling through new or used books stores. Everyone wins. Blargg 08:32, 9 October 2015 (UTC)

An intriguing idea. I don't have the right skill set or the time/bandwidth to learn the necessary skills, but perhaps someone else may be interested. Ahasuerus 03:20, 10 October 2015 (UTC)

Publication/Title Delete fixes

A fairly big patch was installed 20 minutes ago. It changed/corrected the way publications and titles are deleted. There should be no user-visible changes to the way the software behaves, but the change should eliminate "dangling artist" records which used to stay behind when the last COVEART title was deleted. As always, if you see anything unusual, please report your findings here. Ahasuerus 03:29, 10 October 2015 (UTC)

Further tweaks to the way the Title page displayes publications

As per Bug 583, the Title page has been changed to display near-simultaneous editions correctly. For example, the 1928-10-02 edition of Virginia Woolf's Orlando now appears before the 1928-10-11 edition. YYYY-MM-00 pubs will now appear after YYYY-MM-DD pubs. Ahasuerus 23:15, 10 October 2015 (UTC)

The submitter of Bug 583 thanks you :-) Chavey 05:25, 11 October 2015 (UTC)

"Titles without Pubs" made available to non-moderators

A new cleanup report, Titles without Pubs, has been made available to non-moderators. Ahasuerus 14:56, 11 October 2015 (UTC)

Yay, I always wanted more of those reports to be made available to nonmoderators. Thanks! Uzume 18:34, 10 December 2015 (UTC)

Can we get a way to page through the cleanup report results? I understand needing to limit the report queries but I would like to be able to see more than just the first 300 entries of Container Titles in Publications with no Contents. Some of those are somewhat straightforward to fix and others not so much. Thanks Uzume 08:25, 20 January 2016 (UTC)

I'll have to check the code. There may be a better way to retrieve the data from the database. Ahasuerus 02:12, 23 January 2016 (UTC)

Try looking at advanced search results. Uzume 05:45, 23 January 2016 (UTC)

I have poked around. It's a bit tricky. For now I have changed the limit from 300 to 1,000, which should make more titles and publications available for cleanup work. Ahasuerus 01:05, 4 February 2016 (UTC)

Bibliographic warnings for magazines/fanzines

Magazines and fanzines will no longer generate "bibliographic warnings" when they do not have ISBNs or catalog IDs associated with them. Ahasuerus 15:52, 11 October 2015 (UTC)

Thank you! Chavey 18:37, 11 October 2015 (UTC)

Standardization of Publisher names ... ??

Twice in the past three days as I attempt to get a backlog of several hundred paperbacks off my desk, I have had "New Publisher" show up after submitting a new record/change record. Today it was Corgi Books. Someone has standardized it to simply Corgi. Since the late 60s all Corgi editions have Corgi Books on the title page; only the earliest editions had the little dog logo [sometimes with Corgi on it] but no "Books". The other one was Baen. I entered an edition that has Baen Books and apparently THAT is a new publisher. Baen went through various minor changes from Baen to Baen Books and then split to have Baen Science Fiction Books and Baen Fantasy before going back simply to Baen. All this over 20+ years. Someone combined the first three into just Baen but left Baen Fantasy. There is no Community Portal discussion within the last year concerning this, nor one that says the Title Page is no longer the source for a publisher name. Standardization for its own sake is what Locus does, and we've been correcting same from that source for years. I'm hesitant to re-enter the 'correct' publisher names for editions I have as the same Moderator [no editor could do such a sweeping change without it showing up somewhere] could just do this again. --~ Bill, Bluesman 19:56, 11 October 2015 (UTC)

New/Edit/Clone Pub tweaks

There have been some minor tweaks to the way certain fields are displayed in New/Edit/Clone Pub. Most of the changes were behind-the-scenes HTML fixes, but a few are visible to the naked eye, notably the way the separator bar is displayed between Contents title records. Ahasuerus 01:38, 13 October 2015 (UTC)

Self-advertising

I volunteer for a local charity that runs three book sales each year. The sales volume is enough to warrant a separate section (10+ tables) of science fiction and fantasy. In speaking to browsers and buyers about their book, author and series interests, I have had occasion to mention this site a number of times. In spite of being armed with paper and electronic lists, they often only make a mental note of the site address. I would like to pre-print a number of 'cards' with the site URL to hand out. Before starting though, I thought I'd gauge the reaction of active members as to the content, presentation and advisability of such a venture and if there are other considerations or interests. Doug 16:28, 13 October 2015 (UTC)

I see no harm in your proposal, and it may even get us not only new users but, even better, new editors. I say go for it. Mhhutchins|talk 21:15, 13 October 2015 (UTC)

Good idea, Doug. Our late editor Bill Longley (rest in peace, sir) was a great promoter of the ISFDB and even went so far as to make an ISFDB t-shirt to wear at conventions. But I think he only got to wear it once before he passed away. PeteYoung 17:23, 15 October 2015 (UTC)

ISFDB/Wiki outage

ISFDB and the Wiki will be unavailable between 8pm and approximately 8:20pm server (US Central) time. Ahasuerus 00:49, 14 October 2015 (UTC)

Everything should be back up and operational. Ahasuerus 01:21, 14 October 2015 (UTC)

Steve Berry spec-fic?

Is anyone familiar with the work of Steve Berry and can attest to its eligibility for inclusion in the database? All I could determine from listings and reviews is that he writes political/historical novels with no fantasy elements. Mhhutchins|talk 04:58, 17 October 2015 (UTC)

I haven't read his works, but I looked into them when Fixer submitted a few "Cotton Malone" books. They are "secret histories" and feature centuries-old conspiracies, the Knights Templar, shadow governments and so on.

The issue of "secret history" eligibility has been discussed, but I don't think we have a solid consensus. My personal take on it is that they should be eligible if the counterfactual element is significant. For example, if a book is about how human history has been secretly manipulated by the Catholic Church/The Secret Nine/the Knights Templar for the last N centuries, then it's eligible. If it's about a more limited conspiracy, e.g. a plot to kill John F. Kennedy, then it's not. Ahasuerus 13:17, 17 October 2015 (UTC)

But just because one book in the series may have a "secret history" plot doesn't mean that all of them are eligible for the database. From what I've read only the first two Malone novels qualify, and even then just barely. There are far too many "thriller" novels already in the database that are marginal at best. I just don't want to fall down the slippery slope of "Well, if ABC is in the database, then why shouldn't DEF?" (And don't get me started with all of those romance novels by Nora Roberts being qualified for the db.) Mhhutchins|talk 19:08, 17 October 2015 (UTC)

Oh, I agree. I just don't know enough about the series to tell whether volumes 3+ have significant "secret history" elements. Something to ask on a Goodreads forum, perhaps? Ahasuerus 19:15, 17 October 2015 (UTC)

Changes to the way cover indicators appear on the Title page

If you have the "Cover" column enabled on the Title page (under My Preferences), you will now see the name of the site hosting the cover scan. At this time the display values are limited to "ISFDB", "Amazon" and "other", but we can easily make the software display full site names instead of "other" if desired.

Another proposed enhancement is to change the destination page for "ISFDB" images. Currently if you click on "ISFDB", the actual image is displayed. The proposed change would display the Wiki page associated with the image, which will typically have additional information about it, instead. Would that be desirable? Ahasuerus 02:21, 18 October 2015 (UTC)

Yes. Hauck 19:02, 18 October 2015 (UTC)

I've chosen not to see that column displayed, so I tried it. Still didn't care for it. In any case, I'm not sure how a non-editing user who clicks on it would understand about the wiki page for it. Mhhutchins|talk 19:31, 18 October 2015 (UTC)

I don't think it's a good idea to link the the image wiki page for now because I always get "Error creating thumbnail: /var/www/html/wiki//bin/ulimit4.sh: line 4: /usr/local/bin/convert: No such file or directory" in the image area of such a wiki page with Firefox (on Ubuntu 14.04 and 15.04, all add-ons disabled). Google Chrome and Opera work fine, however, and strangely Firefox on Windows works too. I have no idea how Ubuntu's Firefox can lead to such an error on the server side while other browsers don't. This might not be a wide-spread problem, but since Firefox is wide-spread it's probably better to link to the image itself until this problem is fixed permanently. Jens Hitspacebar 08:26, 19 October 2015 (UTC)

Fascinating :) Thanks for sharing! Ahasuerus 04:03, 20 October 2015 (UTC)

Are you sure that's true - for the same image? The fact whether that error comes or not should depend on the size of the image (when > 600 px), not the browser. Issue can be fixed easily by installing ImageMagick on the server, so that "/usr/local/bin/convert" exists. --Stoecker 08:36, 20 October 2015 (UTC)

Yep, same image wiki page URL. Example: this one produces the error, depending on browser version and operation system, like I mentioned above. But your hint regarding the image size was good: it indeed seems to depend on it, because this smaller cover image with 310 × 443 pixels works in all browsers I tested with. Jens Hitspacebar 09:38, 20 October 2015 (UTC)

Ahhh, I just had an idea and found the reason for this strange behaviour: it does not depend on the browser version but on whether I am logged in into the ISFDB wiki or not! So if I'm not logged in it all works fine. If I'm logged in the error depends on the setting for "Limit images on file description pages to" on the "Files" tab in my user preferences. In other words: if the wiki software thinks it needs to create a thumbnail for the image in a wiki page because of the settings it fails. Jens Hitspacebar 09:48, 20 October 2015 (UTC)

Images on the front page?

Is everyone happy with the size/dimensions of the cover scans displayed on the front page? We are currently tweaking the display logic to make the HTML and CSS standards-compliant, so now would be a good time to decide if they need to be made bigger/smaller/etc. Ahasuerus 18:47, 18 October 2015 (UTC)

I'd like to see the covers a little bigger, maybe increase the width by about a quarter? To my eye, at the moment they look too small compared to the size of the type. PeteYoung 04:13, 19 October 2015 (UTC)

Perhaps if you could tell us what the upper limitations are for a "reasonable" size, we could comment/speculate our opinions on the topic. If an additional 10% increase is outside the limitations of reason, then most any comment/speculation would be superfluous. Blargg 21:54, 19 October 2015 (UTC)

I can live with the size displayed. It only takes some time to adjust to it, I'd think. Stonecreek 03:52, 20 October 2015 (UTC)

I would not increase the size. It's on overview, so it should be compact. Better would be a dynamic amount of columns (e.g. 3 or 4 on wide csreens), but I found no way to do that without scripts. --Stoecker 08:38, 20 October 2015 (UTC)

New/Edit/Clone Publication changes

The Web pages responsible for creating, editing and cloning publications have been changed. You may need to force a page refresh (typically Control-F5) in order to see the new layout correctly.

The majority of the changes happened behind the scenes, but a few are visible to naked eye. In the "Content" section, the following fields have been made wider to make it easier to see what you are typing: Page, Title, Author, Reviewer, Interviewee, Interviewer. If this causes any problems, we can undo the changes quickly. Everything else should be the same, so if you see any irregularities, please report them here. Ahasuerus 01:09, 20 October 2015 (UTC)

"My ..." links while editing?

At this time our edit pages display only one "My ..." link, "My Messages". Regular bibliographic pages also display the rest of "My..." links, i.e. "My Preferences", "My Recent Edits", etc. An editor would like to see all of "My ..." links displayed on all edit pages. Any objections? Ahasuerus 16:44, 20 October 2015 (UTC)

Thanks for the suggestion, Ahasuerus. For me, the usual bundle outside the Edit screens is sufficient, though. Stonecreek 17:15, 20 October 2015 (UTC)

No objections. I'd seldom use it, but it wouldn't disturb either. Jens Hitspacebar 18:12, 20 October 2015 (UTC)

COVERART bug fixed

There was a bug in the "Publication Update" code. An attempt to remove a COVERART title from a publication could fail with a Python error if the COVERART record had multiple artists and was shared by multiple pubs. The immediate bug has been fixed, but I am still working on the larger COVERART issue. It will take many more patches to get us where we need to be. Ahasuerus 16:42, 26 October 2015 (UTC)

Are all fanzines "In"?

Are there any constraints on what fanzines should be included in our database? Aside from the issues of priorities, and having the time to get to them, that is. At present, we seem primarily to have listings for fanzines that have won (or been nominated for) the "Best Fanzine" Hugo, along with a few others that editors have decided to add. And many of even those Hugo winning fanzines have minimal support -- e.g. Cry of the Nameless won the Hugo in 1960, so we have title recs for 1958 and 1959, but not for any of the other years of its run (1950-64 and 1968-70). And for those two years with title recs, there are no publications listed, even as "stubs". Altogether, we have partial data on about 250 fanzine titles, while sources such as the Ned Brooks index have over 5000 fanzine titles. Should we be expecting that some day we should have all of those titles indexed with us as well? Or would we want to limit ourselves to some type(s) of subsets? Chavey 16:11, 27 October 2015 (UTC)

I see no reason why any fanzine should be excluded unless it is not specifically devoted to speculative fiction. For example, a fanzine about horror films wouldn't be eligible. But as you suggest, it's a matter of prioritizing. I personally wouldn't allocate much time to creating dummy records when there are hundreds of spec-fic publications listed by Tuck and Reginald that still aren't in the database. But a fan of fanzines would think differently. Mhhutchins|talk 02:19, 28 October 2015 (UTC)

The big difference, to me, is that I have electronic copies of the Ned Brooks list, hence can create scripts to enter them. I have no electronic version of Tuck or Reginald, so all data would have to be entered from the print copies via pounding away at the keyboard. Chavey 04:35, 28 October 2015 (UTC)

For the most part I agree, but "perzines", i.e. "personal zines", may be a grey area. Would a perzine published by Marion Zimmer Bradley be "in"? What about Harry Warner, Jr.? Ahasuerus 02:24, 28 October 2015 (UTC)

Some perzines discuss the author's experiences at cons, visits with other fans, and things of general fannish interest, so I suspect those would be "in". Others are really more strictly personal, e.g. one I remember spent the entire issue discussing the author's health and had no connection with "fandom" outside of the fact that this particular writer was a moderately well-known fan in one region. I would think the former would be included, but not the latter. Fancyclopedia describes a perzine as "a zine written entirely by its [fan editor]. It may have outside contributors, particularly of fanart and [letters], but the bulk of it will be by its originator. Perzines are often diary or letter substitutes, but they may also feature articles, trip reports, book reviews or whatever it occurs to the editor to include." I think those that feature articles, trip reports, book reviews, etc. would be "in". A perzine by MZB, for example, will probably include a poem by her, and that would be surely be relevant. I don't know Harry Warner, Jr's work as well, but my sense is that he often talks about fannish activities going on, including cons and other interactions, and much of that would probably be "in". Chavey 04:35, 28 October 2015 (UTC)

Handling extended notes

The recent discussion of publication series has brought up another issue which will become more important once we start migrating Author Bio/Biblio notes from the Wiki to the database. Consider this publication series. The Note field includes a large HTML table. You have to scroll down almost half way to the bottom of the page before you get to the core data.

That's one of the reasons why I was careful to leave the Wiki page untouched, so we could return to just linking to it if we decided that was better. Chavey 02:12, 19 September 2015 (UTC)

On the author side, take the bio page for Charles G. Waugh. If we were to display this text at the top of Waugh's Summary page, it would take up a significant amount of valuable real estate and force our users to scroll down to get to the core data.

Based on these examples, I'd like to propose that we handle long notes the way IMDB does it: display the basic information on the main page and provide a link to a supporting page with the full text. It would be similar to the way we currently handle tags for authors with more than 20 tags except that the editor would have to explicitly specify the break point -- something like {{BREAK}} should do the trick. The software will display everything prior to {{BREAK}} and then display a link informing the user that s/he can follow it to see additional information. In the case of the previously referenced publication series we would want to put {{BREAK}} right before the HTML table starts. For most authors we could start the Bio text with {{BREAK}}.

Would this work for everybody? Ahasuerus 19:23, 18 September 2015 (UTC)

Doesn't seem the most user friendly. Why not just establish a maximum number of characters that will be displayed on the 'primary' page? The software can then automatically insert the break after the last word prior to that limit. The break tag could be used for manually overriding that. Or just leave it as a separate page like it is today (but in the database). Also, looking at Waugh's bio, it seems like we should establish some standards about what information is included & how it is presented on the new notes page (especially if it will be visible from 'primary' page). When it's on the wiki, there a visual distinction, but once we bring it into the database, that goes away. I would hate to have a user's first impression of the database by made via some the notes we have in the wiki. -- JLaTondre (talk) 23:02, 18 September 2015 (UTC)

I agree that we may want to tweak the wording as part of the Wiki-to-ISFDB migration. Ahasuerus 00:16, 19 September 2015 (UTC)

I think an 'auto' break function would need to be smart enough to break outside any html markups... otherwise it will leave unmatched pairs of <>. And that doesn't sound easy to code. Kevin 23:16, 18 September 2015 (UTC)

That's right, embedded HTML, especially tables, is one of the issues here. Another difficult issue is the inherent complexity of some Notes values. For example, if it says:

Current address of this publisher:
  14 Infinity Court
  Dreamville, Illinois, USA

it would look bad if we cut it off after "Dreamv". There are just too many different types of cases requiring a variable number of characters before there is a logical break point. Ahasuerus 00:07, 19 September 2015 (UTC)

I think IMDB prohibits html tags in those fields that use "Read More..." type elements. But to allow html tags, I think having a manual {{BREAK}} might be almost mandatory. We could, however, have a warning to the editor & moderator if a field goes too long, and a cleanup report to find such things. Chavey 02:12, 19 September 2015 (UTC)

(unindent) FR 545 has been updated. Ahasuerus 21:34, 1 October 2015 (UTC)

The {{BREAK}} functionality has been added to all record types that support notes, i.e. titles, publications, publishers, series, awards, award types, award categories and publication series. The Masterpieces of Science Fiction has been updated as per the discussion above. I will be updating Help shortly. If you run into anything unexpected, please report your findings here. Ahasuerus 22:17, 1 October 2015 (UTC)

I like it. Works fine for me, except maybe the "View Full Note" might be bolder. Maybe yellow background with black text? Mhhutchins|talk 23:57, 1 October 2015 (UTC)

Well, I am colorblind, so I will happily defer to all you color-enabled folks. My only concern is consistency. We currently use the same "inverted" style for extended notes, extended author tags (see Kim Stanley Robinson's Summary page), the "VOTE" button, the tag management button and a few other things. If we change the color scheme of this style, it will affect all other pages that use it. Of course, we could create a new style just for extended notes, but I think there is value to being consistent: it makes it easier for new users to navigate the site. Perhaps we could make the font bigger instead? Or use all uppercase? Ahasuerus 00:13, 2 October 2015 (UTC)

I see your point about being consistent, so maybe a larger font would help. Uppercase may be too much (don't want to SCREAM!) but if you could show us samples then we could choose among them. Thanks. Mhhutchins|talk 02:20, 2 October 2015 (UTC)

HTML has tags to make things "big" and "small" (we use the latter for derived ISBNs), so it was easy for me to make the message "big". Does it look better now? Ahasuerus 15:35, 2 October 2015 (UTC)

With the screen with I'm viewing the page on at the moment, the "View Full Note" is half on one line and half on another; I would consider adding white-space:nowrap to the CSS of the inverted link class. Albinoflea 17:29, 2 October 2015 (UTC)

The "big" option looks better, but I would go with Albinoflea's suggestion to make it nowrap. Thanks. Mhhutchins|talk 18:00, 2 October 2015 (UTC)

Done. Some browsers may require a hard refresh (Control-F5) before they recognize the layout change. Ahasuerus 20:31, 2 October 2015 (UTC)

Large notes like this are another reason to employ some sort of markup language instead of just raw HTML. I would rather see the use of CSS (e.g. <span style="font-size:large">...</span>) over the user of "big" tags. BTW, instead of showing the summary with server-side code, you could also just provide the link to the note and have client-side Javascript code fetch and provide the summary/preview (rewriting the link). It would be a little easier on the server but would not work for non-Javascript users of course. Uzume 19:49, 10 December 2015 (UTC)

Wiki style formatting in comments

A lot of publications use links to WorldCat and the German ones to DNB. Others link to translators, other pubs and titles. That's a lot of linking and each time style differs and HTML syntax requires duplicating data in link and display data.

I'd like to have an

• {DNB:958577617} replaced by "<a href="http://d-nb.info/958577617">958577617</a>"
• {OCLC:55628676} replaced by "<a href="http://www.worldcat.org/oclc/55628676">55628676</a>"
• {author:Eric Frank Russell} replaced by "<a href="http://www.isfdb.org/cgi-bin/ea.cgi?Eric%20Frank%20Russell">Eric Frank Russel</a>"
• {author:51} replaced by "<a href="http://www.isfdb.org/cgi-bin/ea.cgi?51">Eric Frank Russel</a>" (needs a database lookup to display the name)
• {pub:...} and {title:...} as well

The change would be straightforward and seems to affect only one function FormatNote(). Other stuff can be added later when needed. This work work for all Notes field in the database. Beside the easier editing it would allow to find references much easier and automatic which could help to catch e.g. stray links to ISFDB resources deleted in between. --Stoecker 17:03, 6 October 2015 (UTC)

Wiki style formatting doesn't work in the Note field of a database record. HTML must be used. If I understand correctly, are you saying that there are records in the database that try to link using Wiki markup? I'm not familiar with the format using the curly brackets that you've given in the examples above. They're used in Wiki for templates. How would they work in database records? (I'm assuming by "comments" you mean the Note field of a database record, and not Wiki posts.) Mhhutchins|talk 17:47, 6 October 2015 (UTC)

I believe he's proposing to implement a parser that would look for {OCLC:55628676} etc. I'm happy with the idea in general but I see that it'll cause some duplication in the text and I believe it would be better to implement a language looks closer to wikitext. By duplication I mean that 99% of the time we will type "OCLC {OCLC:55628676}" and so why not have "{OCLC:55628676}" output "OCLC <a href="http://www.worldcat.org/oclc/55628676">55628676</a>"?

I believe our fingers and brains would be happier if the shortcuts were: {{DNB|958577617}}, {{OCLC|55628676}}, {{author|Eric Frank Russell}}, {{author|51}}, {{pub|...}} and {{title|...}}. It would look like we are using wikitext and later, allows us to use the full wikitext engine.

BTW, I'd love to see * at the start of a line expanded to the bullet character some people use. Extra credit if you figure out how how to generate <li>...</li> which is not as easy as it seems as you need to see if you are inside a <ul> and if not to generate one that surrounds blocks of <li>. The challenge is you are already inside a <ul> block at the start of a note. --Marc Kupper|talk 17:58, 6 October 2015 (UTC)

I believe Marc's interpretation is correct. It's an interesting idea, but first let me describe the history of the Note field.

20 years ago, when the first version of the ISFDB software/database was being designed, there were very few Web sites which hosted biographical data about SF authors. For this reason we thought it was important to add a "biography" field to Author records, which Al eventually implemented as part of ISFDB 1.0. By the time ISFDB 1.0 was retired, 595 author records had brief biographies associated with them. These biographies are still stored in the current ISFDB database, but there is no way to view or edit them. Some of them use a special template syntax to link to other author records and to IMDB. (Of course, we don't need to link to IMDB in Notes now that we have a separate Webpage field.)

10 years later, when ISFDB 2.0 was being (re-)designed, Wikipedia was the "latest and greatest thing". Al and I figured that Wikipedia would be a better place to keep the biographies of "major" authors. We also decided that the biographies of any authors ineligible for separate Wikipedia pages would be stored in the ISFDB Wiki, which is why there is no "Biography" field in ISFDB 2.0's Author Editor.

In retrospect, there were numerous reasons why it was a bad decision. For example, Wikipedia's "notability" criteria have changed over the years and may change again. There is no guarantee that articles about less prominent SF authors will still be there in 5 years. Storing data in the ISFDB Wiki is also problematic because of the disconnect between the database proper and the Wiki as well as other issues like the lack of moderatorial oversight. I plan to re-add the "Biography" and "Author" field to the database and migrate the data from the Wiki to the database in the near future as per FR 307. (Details to be discussed RSN.)

Another issue that has come up over the last few years is adding support for external identifiers as per FR 235:

• Add support for external identifiers at the Publication and Title levels. Publication identifiers can include LCCNs, Worldcat IDs, British Library Ids, Goodreads IDs, etc. Title identifiers can include "Work" identifiers used by LibraryThing, Goodreads and other social cataloging Web sites.

The original idea was to add a new infinitely repeating group of two fields in order to support this functionality. The first field would list the supported sources of external identifiers (LCCN, OCLC, DNB, ASIN, etc) and the second field would let editors enter the source's ID. When displayed on Publication/Title pages, these IDs will be automatically linked to their sources.

If implemented, these fields would supplant much of the functionality discussed in Dirk's proposal. On the other hand, it would take many more man-hours to implement: we'd need new database structures to support them and a number of edit/review/approve pages would need to be modified.

So I guess the first question that we need to answer is whether adding these two new fields to support "external identifiers" is a better long term solution than enhancing Notes to simplify data entry. Ahasuerus 00:42, 7 October 2015 (UTC)

I believe that working on the creation of a repeating field for external identifiers should have priority over enhancing the Note field. That's if we have to make a choice. Mhhutchins|talk 01:14, 7 October 2015 (UTC)

Unindent: Responding to some of the thoughts above:

• {{DNB|958577617}} style would be fine for me as well
• Why not include texts like OCLC: Yes, that means more typing, but keeps the current flexibility of use, as only the link which contains additional information is replaced. That leaves the chance to add more than one entry, use it in texts, ...
• Replacing * or li or ...: That's out of scope. I don't want to add a wiki style syntax, but allow to have links support in a way, that automatic analysis is possible for reference checks. Currently with full HTML that's nearly impossible. Shorter typing is only a nice side effect
• I know the idea to have separate fields since I started with ISFDB. There was no progress since then. I also see no chance with such a massive change with the current development model. What I propose is an easy patch which does not require massive changes (It's a 40 lines patch approx, I already have a running test on my instance).
• The change gives us a fast solution to proper linking which allows to use database functionality for reference checks. Database handling will be a bit more complicate than with individual fields, but at least it will be possible at all - and that's a programmers task, not a user issue.
• In case the more complex solution will come, the Wiki style variant may still be required and data fields can be auto-populated for the existing texts by a simple database run. So even if you still want to target that database changing solution, the Wiki-Style now would be a good idea. --Stoecker 07:04, 7 October 2015 (UTC)

See an example at work here: http://isfdb.stoecker.eu/cgi-bin/pl.cgi?536518 (valid till saturday), patch here: http://isfdb.stoecker.eu/patches/07_wikisyntax.patch (in the unlikely case that one of my patches gets applied: the style argument of span should be a class "wikierror" and the format go to css). --Stoecker 15:48, 7 October 2015 (UTC)

I see a number of concerns with this. I would prefer supporting more identifiers but currently we allow raw HTML in note fields to be rendered as such which is a security concern (of course submissions go through moderation). I also am not particularly pleased with the DBs dependence on our instance of MediaWiki software (which is highly outdated)—especially the authentication system but it also applies to notes, biographies, images, etc. If we really want to add a markup language I recommend looking at Comparison of document markup languages and something like reStructuredText or Markdown. Uzume 18:59, 10 December 2015 (UTC)

Wrap-around art?

Is there any sort of policy, spoken or unspoken, about uploading full wrap-around cover art as opposed to just the front cover? I appreciate there would be some resolution loss to adhere to the 600 pixel limit, but there are some great full covers out there... Thanks, Astrodan 13:46, 15 October 2015 (UTC)

Full wrap-around cover art images are fine (examples: A Plague of Angels, A Wizard of Earthsea). -- JLaTondre (talk) 16:36, 15 October 2015 (UTC)

Exceptions are made for wrap-around art, but it's suggested that you keep the file size to less than 200 KB, and the height of the image to 600 pixels or less (with a resulting longer length, of course). Mhhutchins|talk 17:46, 15 October 2015 (UTC)

I've done one or two wrap-around art image uploads, keeping the longer width dimension to less than 600 pixels, which went through ok, but I've just tried one following your suggestion in the second paragraph above, i.e. keeping the height to less than 600 pixels, which was unsuccessful. After doing the Upload Cover Scan/Upload file process, during which I got an Upload Warning that my file was 169kb, not 150kb or less, the Image...jpg page opened with a greyed-out rectangle showing the following message: "Error creating thumbnail: /var/www/html/wiki//bin/ulimit4.sh: line 4: /usr/local/bin/convert: No such file or directory"

Does this mean the system is sticking rigidly to the "600 pixel longest dimension" rule, or is it something else? The image is for my copy of Green Mars, and the Image...jpg page is here. Astrodan 12:38, 1 November 2015 (UTC)

Nope, it means our wiki is not properly configured. You will see that error message when images are larger than the image size in your wiki preferences. You have two options to see the image:

1. You can click the "Full resolution" link below the grey box. That is the same as clicking on the preview image and will display the image in its own window. You can then copy the URL to the publication record.
2. You can click the "my preferences" link at the top of any wiki page (assuming you are using the default skin), select the "Files" tab, and then increase the image size in the "Limit images on file description pages to:" setting. The image should now be displayed in the regular Image page.

-- JLaTondre (talk) 12:53, 1 November 2015 (UTC)

Thank you, a very clear and helpful explanation. Astrodan 15:04, 1 November 2015 (UTC)

"Add quick tag" - display change

The recent flurry of software patches has been primarily about implementing Dirk Stoecker's fixes to eliminate various HTML bugs. As such, they are mostly invisible to the naked eye except for a few minor positioning tweaks. The only functional change has been the addition of "select a value" as the default for "Add quick tag" on the Title page. Does it look OK? Should we make it all-uppercase? Mixed case? Revert to the original behavior, i.e. a blank space between "Add quick tag" and "Submit Tag"? Ahasuerus 01:14, 17 October 2015 (UTC)

I think this works fine, and I don't mind the lowercase; I'd maybe add a little padding between the Submit Tag button and the tags in the line above it. Albinoflea 01:47, 3 November 2015 (UTC)

OK, I have added 2 pixels worth of extra padding. How does it look? Ahasuerus 03:20, 3 November 2015 (UTC)

URL validation

Edit Author has been modified to validate Web page URLs and author image URLs at submission time. The validation logic checks that they start with "http://" or "https://". The rest of the Edit pages will be modified tomorrow. Ahasuerus 01:32, 21 October 2015 (UTC)

Done. I have also added pop-up validation to "Parent Position" in Edit Series and "Display Order" in Edit Award Category. Ahasuerus 03:48, 22 October 2015 (UTC)

So if one becomes a significant author one cannot have web pages on Gopher anymore—no loss there (most browsers no longer support this anyway). BTW, scheme relative URI/URLs are valid, e.g., //www.google.com/ (even if this old version of MediaWiki we are using does not link such). Thanks. Uzume 18:17, 10 December 2015 (UTC)

Pop-up validation and "Add..." buttons

A few days ago, when I started working on the proposed COVEART changes, I realized that the part of our software responsible for the "Add ..." buttons and pop-up validation had grown unwieldy and fragile. Instead of adding more COVERART-related complexity to it, I decided to streamline the software first. It's a relative simple set of changes, but they require a lot of typing, so typos are a potential issues. If you see anything odd happening, please post your findings here. Ahasuerus 01:08, 26 October 2015 (UTC)

Publication image URL validation, which was broken a couple of weeks ago, has been fixed and enhanced. Ahasuerus 01:52, 26 October 2015 (UTC)

This is an area where I always wanted to improve the Web API and make the Javascript used in the web edit interfaces use the Web API to get its data from. It would also allow us to add features like auto-completion (e.g., author names; you probably have seen how Open Library handles things), etc. Uzume 18:28, 10 December 2015 (UTC)

Editing issues when using Chrome and Internet Explorer

Please note that editing is currently (mostly) broken when using Google Chrome or Internet Explorer. It turns out that a certain very useful feature allowed by Firefox is not supported by these other browsers. I expect to fix the problem by the end of the day. Ahasuerus 16:41, 30 October 2015 (UTC)

OK, I believe the latest patch fixed the bug.

Also, this was the last patch in a long series of enhancements which had to be implemented before I could start working on the COVERART changes. If you see unexpected behavior, please report it here. Ahasuerus 18:58, 30 October 2015 (UTC)

Further editing tweaks

The way NewPub pages work was tweaked a few minutes ago. You may need to refresh the biblio page that you currently are on before you click on an "Add New ..." link. Ahasuerus 02:15, 1 November 2015 (UTC)

Changes to "Add Publication to This Title"

"Add Publication to This Title" has been changed to allow entering Contents items. In addition, the "Add Title" button is now context-sensitive: if you click it when working on an OMNIBUS publication, it will display "NOVEL" as the default title type. Ditto NONFICTION pubs and ESSAY titles.

This was a side effect of the cleanup work needed to make the requested COVERART changes. A lot of other things have been tweaked, but they should be either transparent or correct very minor bugs. Ahasuerus 03:04, 3 November 2015 (UTC)

Green Earth and the Science in the Capital / Capital Code series

I've been thinking about this since this title was first mentioned in an interview but figured I'd wait to get my hands on a copy before I did anything.

The three books in the Capital Code series were abridged by KSR and published as a single volume titled Green Earth. The tagline on the cover reads: "The Science in the Capital Trilogy / Revised Edition / Published for the first time as a single thrilling novel!"

The title page reads: "Green Earth / The Science in the Capital Trilogy / Forty Signs of Rain / Fifty Degrees Below / Sixty Days and Counting". The book is broken into three parts, each labelled with the name of the original book, but the chapters 1 to 30 are spread across the three parts. In the introduction KSR says that the length of the trilogy was reduced by about 27% (1100 pages down to 800) for the new publication.

So, the questions I want to put to the group are:

• Should this pub be an Omnibus?
• Any objections to changing the title of the series from "Capital Code" to "Science in the Capital"? And if so, is it necessary to contact and PV'ers of the books in the series, or is posting it here for open content enough?

I don't have strong feelings about this one way or the other, just want to get a feel for how other folks would handle this. Thanks, Albinoflea 00:16, 4 November 2015 (UTC)

A 27% reduction in the number of pages and a rearrangement of the first 30 pages chapters sounds pretty major. Perhaps it would be better to keep it as a separate NOVEL title with supporting notes. Ahasuerus 01:45, 4 November 2015 (UTC)

I agree with Ahasuerus about keeping it a separate title without variant. I also believe you should keep it as part of the series, and the series title should be the author's own designation. Title records aren't primary verifed, so it isn't necessary to notify the PV editors of publication records under that title about s change in any field of a title record, including the series. Mhhutchins|talk 05:09, 4 November 2015 (UTC)

Same opinion here: it sounds like a major revision to me. Stonecreek 07:16, 4 November 2015 (UTC)

Thanks for the feedback; I've changed the Series name and added appropriate pub and series notes. Albinoflea 03:34, 7 November 2015 (UTC)

COVERART redesign

With the preliminary cleanup out of the way (see above), I am experimenting with different COVERART designs. Here are my thoughts so far.

Back when the ISFDB 2.0 software was created in 2004-2005, we could have designed NewPub/AddPub/EditPub to handle COVERART records like regular Contents titles. However, there were two reasons why we didn't do it that way. First, it was our assumption that a publication could have only one COVERART title associated with it. Second, we didn't want to force our editors to re-type each publication's title in the Contents section whenever they entered COVERART information. Hence the original design, which moved the COVERART information from the Content section to the publication-specific section of the data entry forms and limited it to a repeatable "Artist" field. That way the editor only needed to enter the artist's name(s) and the software created a COVERART title behind the scenes. (Note that this is similar to the way the software automatically creates a new "reference" title record for new publications.) In addition, the software was tweaked to automatically delete COVERART titles whenever the last publication associated with them had been deleted. The basic idea was to make entering/deleting publication data less time-consuming.

A few years later we realized that our original assumption had been incorrect and that publications could have more than one COVERART title associated with them. We tried to adjust the software to support this scenario, but the results were inconsistent at best and misleading/incorrect at worst. Most notably, the NewPub changes resulted in the creation of multiple COVERART titles whenever two or more artists were entered, which was, more often than not, not the intended behavior. So now we have to go back to the drawing board. (Except for the automatic deletion of orphan COVERART records, which seems to be working well.)

The most obvious solution would be to undo all of the complexities/inconsistencies that have been introduced over the years and to treat COVERART records the way other Contents titles are handled. It would make adding/removing/editing COVERART titles much more straightforward at the cost of requiring our editors to enter each COVERART record's title in the Contents section of the New/Add Publication Web page. The "Artist" field would disappear and all COVERART-specific editing would be done in the Contents section. I call this approach Plan A.

Another approach, which I call Plan B, would be a hybrid solution, combining certain elements of Plan A with some elements of the current design. It would keep the "Artist" field on the New/Add Pub pages only, but change its behavior to create only one COVERART record when multiple artists are entered. Any additional COVERART titles would need to be entered as separate COVERART records in the Contents section. The "Artist" field would be removed from the Edit/Clone Pub pages and any COVERART additions/modifications would be performed in the Contents section. "Remove Titles from this Pub" would be modified to allow the removal of COVERART titles.

The main advantage of Plan A is that it makes everything consistent and straightforward at the cost of making the data entry process more time-consuming. The main advantage of Plan B is that it preserves the current, more efficient, workflow of the New/Add Pub pages at the cost of making them behave differently vis a vis the Edit/Clone Pub pages. I don't think it would be too confusing considering that the New Pub page already behaves differently than the Edit/Clone Pub pages.

My current thinking is that Plan B would work better than Plan A, at least in the long run. Does it sound about right? Are there any other approaches that may work even better? Ahasuerus 18:42, 4 November 2015 (UTC)

Have you considered handling COVERART like we currently handle CONTENTS, REVIEWS, and INTERVIEWS? Create a separate entry section for the cover art, and have the ability to "Add Cover" (as we now "Add Title" for the other content section) and to "Add Artist" under each entry (as we now "Add Author" under the other content sections). It would be consistent with all other contents in the way it's entered, but have its own section on the entry form. Mhhutchins|talk 23:31, 4 November 2015 (UTC)

Hm, no, I haven't. Let's think about it. Basically, the reason that we have three separate Contents sections is that reviews and interviews have additional fields ("Reviewer", "Interviewer") that regular titles do not have. The situation with COVERART records is somewhat similar. They differ from regular titles in that they don't have page numbers associated with them. If we segregate them in a separate Contents section, we will also be able to get rid of the "Entry Type" and "Length" fields, which will leave us with just three fields -- Author(s), Title and Date -- per COVERART record. I think that should work quite well for Edit/Clone Pub submissions.

However, I think that the situation with New/Add Pub submissions is different. When filling out a New/Add Pub form, the values of the Title and Date fields of the COVERART title are currently set to the title and date of the new publication (except that the COVERART record's title has "Cover: " added.) This functionality seems useful and worth preserving since it eliminates unnecessary typing when entering new records. We'll just need to think of a way to combine it with the proposed design changes... Ahasuerus 03:25, 5 November 2015 (UTC)

You needn't have a title or date field in the new section which I propose. There would be a single field for the artist, followed by a button to "Add Artist" (if the art is collaborative). The system would then create a new COVERART record using the data provided in the title and date fields of the metadata section. You would then have the option to add another COVERART record with an "Add Cover" button which opens up another artist field (just as there is an "Add Title" button in the Contents section, an "Add Review" in the Review section, and an "Add Interview" in the Interview section.) Mhhutchins|talk 03:44, 5 November 2015 (UTC)

Oh, I see. Yes, I considered it about 6-8 weeks ago when we had the last discussion of COVERART issues. I though that the approach might work for New/Add Pub submissions, but there were two caveats.

First, I think it's important to show full COVERART record(s) on the Edit Pub page. That way the editor can see the title and the date of the COVERART record(s) and adjust them if needed. (If a COVERART title is shared with other pubs, its fields will be greyed out, of course.) It will also make COVERART records' appearance and behavior consistent with other record types.

Second, I was concerned that having an "Add Cover Art" button next to the current "Add Cover Artist" button may be too confusing, especially to casual editors. That's why I thought that, on New/Add Pub pages only, it may be better to keep the current "Add Artist" functionality for the first (and usually only) COVERART record. Any additional COVERART records could be entered in the Contents section. On second thought, I am not sure which approach would be more confusing :-\ Let me sleep on it... Ahasuerus 05:58, 5 November 2015 (UTC)

Good morning! Over here, I have already slept over it and I do find Plan B more striking. Would the new COVERART behaviour be in any way affected by unknown artists (for example new additions supplied by Fixer (would there be in any case a COVERART title created)? Stonecreek 08:13, 5 November 2015 (UTC)

Yes, COVERART titles will still be created for new publications. And I don't think the proposed changes will have any effect on how unknown artists are handled. Ahasuerus 14:30, 5 November 2015 (UTC)

I believe that having one cover art entry in the metadata section and another in the content section to be too confusing, even for current editors. It also creates a false hierarchy that doesn't exist for publications which have more than one cover. Why should one cover have priority over the other? Also, if a button is clearly marked "Add Artist" and the other is "Add Cover", I can not see how it can be confusing, even for casual editors. It's clearly two different functions. Mhhutchins|talk 19:09, 5 November 2015 (UTC)

OK, you have convinced me :-) I plan to work on New/Add Pub changes first. Once they have been deployed and reviewed, we'll be in a better position to decide what we want to do with Edit/Clone Pub. Ahasuerus 19:53, 5 November 2015 (UTC)

I'll also vote for Mike's suggestion. If you are concerned about confusion over the two buttons, one option might be to have a confirmation dialog for the (relatively uncommon) "New CoverArt" button, along the lines of "You are about to create an additional cover record. This usually means a 'double' book, with covers on the front and back, or a cover composed of several separate covers. Was this your intent? [ Confirm ] [ Cancel ] " Chavey 16:50, 7 November 2015 (UTC)

An interesting thought. I am actually working on Import/Export Contents today. Since the "Publication Metadata" section of the second page is display-only, it will give us an opportunity to review and tweak (some of) the proposed changes without affecting the data entry process. Ahasuerus 17:05, 7 November 2015 (UTC)

COVERART redesign -- First Changes

The first COVERART patch was deployed a few minutes ago. It modified the way the second "Import/Export Contents" page handles COVERART records.

If you display a publication with two or more COVERART titles like Naked in Death and try to import the contents of another publication into it, you will see a new section below "Note to Moderator". This section, "Cover Art", displays the COVERART records that are currently associated in the pubs and is meant to showcase the proposed page layout.

Once we tweak the layout to our satisfaction, I will re-use it in Edit Pub and Clone Pub. I will also remove this section from the Import/Export page because it's supposed to show the titles that are about to be added to the currently selected pub rather than the titles that are already associated with it. Ahasuerus 02:26, 8 November 2015 (UTC)

Availability update

Just a note that some pesky "real life" issues have popped up and my availability may be unpredictable in the near future. I hope to know more in the next few days. Ahasuerus 08:24, 9 November 2015 (UTC)

A quick update.

The bad news is that a small part of my collection has been severely damaged (I should have known better than to trust the Aldebaranians!) The rest will be sporadically unavailable while I reorganize and rebuild, which will likely take a number of months. I don't think any of my verified pubs were lost, but I won't know for sure until later.

The good news is that I expect to be able to continue working on development/Fixer while the recovery operation is underway, although some things will take longer. Ahasuerus 20:50, 10 November 2015 (UTC)

Ouch! Hope your house is ok. Chavey 15:21, 11 November 2015 (UTC)

The damage is in the five-figure range, but it's not as bad as it could have been. Moving and re-shelving thousands upon thousands of books and magazines will be the painful part. At least the development server (and lesser life forms) were not affected! Ahasuerus 16:41, 11 November 2015 (UTC)

Gahan Wilson's The Science Fiction Horror Movie Pocket Computer

We have this item as an essay, but there'd also a dissenting view of it possible: a shortstory with an introduction. I would prefer yet another way of looking at it: a two-part split into an essay & a story. Anyway, I have to add a story version of it to a publication and can live with a change to SHORTFICTION or a split-up (for the essayistic part is missing in the book). Any comments are welcome. If there are none I would undertake the change in two days time and add an ESSAY where it is possible. Stonecreek 19:40, 12 November 2015 (UTC)

If parts of it were removed to create a short story, then it should be handled as a separate work with linked notes. That is, if I'm understanding you correctly. Mhhutchins|talk 19:55, 12 November 2015 (UTC)

Well, Wilson introduces on one page a flow diagram. The introduction in essence states that it's now possible to waste no more time watching catastrophe movies. The story in the diagram starts with two possibilities: Earth a) burns up or freezes or falls into the sun, or b) is struck by a giant comet. Each of the two scenarios offers two and respectively three further developments (and so on, and so on). The further story and its end depend on which way you chose. It's all a satire, of course (first published in the magazine The National Lampoon). Stonecreek 20:13, 12 November 2015 (UTC)

My apologies: I overlooked that in fact, there are four possiblities: also scientists and aliens put Earth in danger. Stonecreek 11:27, 13 November 2015 (UTC)

It appears to be a facetious (non-fact) article, but since we don't have such a category on the ISFDB, we have to determine which single category, SHORTFICTION or ESSAY better applies. Since the author is trying to more present a viewpoint about story writing than he is in telling a story, then I'd consider it an ESSAY. I don't think breaking it into two parts is a good idea. It's a singular work, even if parts of it were extracted in the version you have. Why not just add a note in the title record that the some parts of it as published in X were removed? Mhhutchins|talk 00:02, 13 November 2015 (UTC)

No, I disagree. When you follow a chosen path you end up with a story told. So, the second part is a (multi-faceted) story with an introduction, with both parts about the same length. Why should a story that is similar in its flow diagram structure to this story, when it is published without the introduction be categorized as an essay? Stonecreek 11:27, 13 November 2015 (UTC)

I can only go by your description, and what you first described is a facetious article. I will leave this discussion and allow you and the other primary verifiers determine which is the better of the categories for it to be placed. In either case, it shouldn't be spit into two records. Mhhutchins|talk 16:54, 13 November 2015 (UTC)

Why not? We do have introductions for fiction as separate entries. And in this case, one page of an introduction should be enough in length to qualify as separate entry. Stonecreek 05:22, 14 November 2015 (UTC)

I made the change, and will add an additional essay (with a note being the introduction) to some publications where its place is obvious or safe to assume. Stonecreek 08:25, 17 November 2015 (UTC)

Perma-Bound publications

Ran across an interesting copy of this publication of Andre Norton's Lord of Thunder which is listed as a pb. Mine was a hardcover. It caught my attention because it was so small - just slightly larger than the paperback. There was a sticker with "Perma-Bound", "Pat. No. 3,161,423". Seems there's a service that will re-bind books for schools and libraries to make them more durable. The book is from 1984, but it looks like they're still in business. I thought I'd note it here in case anyone searched the wiki. Doug 23:03, 14 November 2015 (UTC)

You can create an ISFDB record for it. There are hundreds of records for several "re-binders" in the db. Clone the existing record, change the publisher to Perma-Bound and the binding to hc. Remove any price unless there's a separate one stated. If there is a separate ISBN stated, replace the one in the record. (Sometimes the new ISBN is only on the cover but not inside because it's a copy of the retail edition.) Also, add further explanatory notes. Mhhutchins|talk 00:40, 15 November 2015 (UTC)

I actually just had a conversation with a Customer Service Rep at Perma-Bound about 2 weeks ago; they've only been assigning their own ISBNs to books for the last three years, so anything older will only have the original publisher's ISBN internally. Albinoflea 03:27, 15 November 2015 (UTC)

Entry created here. Doug 13:20, 16 November 2015 (UTC)

Somewhere around here, or not, I have at least one Ace Double that has been rebound for the library market. Very odd to see something like that. MLB 08:08, 11 January 2016 (UTC)

COVERART changes - Phase 2

I am about to install a patch which will change the way COVERART titles are created for NewPub and AddPub submissions. Patch notes to follow. Ahasuerus 22:31, 15 November 2015 (UTC)

NewPub and AddPub have been changed as follows:

• The "Artist(s)" field, which used to be available in the "Publication Data" section of the data entry form, has been removed.
• A new section called "Cover Art" has been added between the "Publication Data" section and the "Content" section. It lets you enter one or more artists responsible for the book's/magazine's cover. If there are additional covers (dos-a-dos books and such), you can click on "Add Cover", which behaves just like the "Add Title" button in the Content section.
• The Submission Review/Approval pages for these submission types have been modified to support the "Cover Art" section.

In addition, the way ClonePub handles artist addition, which was broken in the previous patch, has been fixed. It's just a band-aid until I rewrite ClonePub and EditPub to use the new way of handling COVERART records.

Please note that you may have to force a "hard refresh" within your browser to make "Add Artist" and "Add Cover" to work. In most browsers the key combination is "Control-F5".

As always, if you run into any issues, please post your findings here. Ahasuerus 22:51, 15 November 2015 (UTC)

Thanks for the changes. It looks great so far. I'll report if I find any glitches. Mhhutchins|talk 22:59, 15 November 2015 (UTC)

COVERART changes - Part 3 - Removal of COVERART titles from publications

"Remove Titles From This Pub" has been modified to let editors remove COVERART titles from pubs. Ahasuerus 18:50, 16 November 2015 (UTC)

COVERART changes - Part 4 - Clone Publication

I am about to start working on changing Clone Publication to support the new way of handling COVERART titles. At the moment cloning a pub with an attached COVERART record results in the creation of a new COVERART title. In addition, if the original COVERART title has multiple artists associated with it, the cloning process will create one new COVERART title per artist. (Yes, it's a mess.)

As previously discussed, the "Clone Publication" page will be modified to have a "Cover Art" section, which will be similar to the one that the NewPub and AddPub pages already have. However, first we need to decide how we want the cloning process to behave when dealing with the following 4 scenarios:

1. The original pub doesn't have a COVERART title(s) attached
2. The original pub has a COVERART title(s), but the new pub won't have one (either because there is no cover art or because we don't know who the artist was)
3. The original pub has a COVERART title(s) and the new pub has the same COVERART
4. The original pub has a COVERART title(s), but the new pub has a different cover

I can think of only one solution which will let us support all 4 of these scenarios. Here is my proposal:

• Add an intermediate Web page to the Clone Pub process
• The new page will appear after the editor clicks "Clone This Pub" but before the main "Clone Publication" page
• The new page will have a single check-box which will let the editor specify whether the new publication should share the COVERART title(s) with the old one
• The new page will only appear if the original pub had a COVERART title attached to it
• If the editor checks the box on the new page, the main "Clone Publication" page will display the COVERART title(s) associated with the original pub. They will be greyed out just like other shared titles are greyed out. The editor will be able to use the "Add Cover" button to add another cover.
• If the editor doesn't check the box on the new page, the main "Clone Publication" page will display a blank "Cover Art" section

What do you think? Ahasuerus 19:51, 16 November 2015 (UTC)

I think that's the way to go, even if some editors may be thrown off by the intermediate page. It seems simple enough that they should understand what is being asked of them. Thanks. Mhhutchins|talk 20:39, 16 November 2015 (UTC)

I agree. One further thought, though: You should consider the other content, too, and also think about Import/Export, and whether anything else about cloning could take advantage of this intermediate page. For example, one thing deemed useful to include in import/export was page number control... Could Clone benefit from anything similar? I could see a few other useful options on your proposed intermediate page: Keep content page numbers? Keep interiorart? (this might even be useful on Import/Export). Oh, and I miscounted; a second, unrelated thought: It might be helpful for the intermediate page to display the cover image + artist credit right on that page. --MartyD 14:23, 17 November 2015 (UTC)

Excellent points, thanks! Ahasuerus 15:05, 17 November 2015 (UTC)

(unindent) Speaking of Clone Publication, I am not sure the text displayed in the "Content Section" would make a whole lot of sense to a new editor. Here is the current wording:

• This tool performs a clone operation on a publication. You may add titles, but you cannot delete or modify titles. Modification of a title requires knowing whether you intend to modify the canonical title or wish to create a variant title. If you need to change the canonical title, do so before cloning the publication. If you need to create a variant title, first clone the publication, and then go back and make repairs after integration.
• The existing titles listed here will be automatically merged. Any new titles you may add will need to be manually merged.

Does it look as cryptic as I think it does? Ahasuerus 19:09, 17 November 2015 (UTC)

Since an editor can't modify titles during the clone function, then everything after the second sentence of the first bullet (starting with "Modification of a title...") seems unnecessary. If a new editor feels the need to change a content title, they probably shouldn't be considering using the clone function at this point in their editing of the ISFDB. They should already be familiar with editing titles.

I suggest changing the second sentence of the second bullet to "Any added titles (or Any titles you add) may need to be manually merged" (instead of "will", since they could be new titles.) Mhhutchins|talk 21:03, 17 November 2015 (UTC)

Sounds good, I'll make the change. Thanks! Ahasuerus 18:09, 18 November 2015 (UTC)

Done. Ahasuerus 19:08, 19 November 2015 (UTC)

(unindent) Clone Publication has been changed as per the discussion above. The new intermediate page displays the current cover image (if one exists) and lets the editor decide whether to reuse COVERART titles, INTERIORART titles and page numbers.

The main Clone Publication page has been updated to include a "Cover Art" section. If there are no pre-existing COVERART titles, the "Cover Art" section looks the same as the "Cover Art" section on NewPub/AddPub pages. Otherwise, the pre-existing COVERART title(s) are displayed and the editor is allowed to add additional COVERART titles.

As you would expect, quite a few things had to be tweaked behind the scenes to support these changes. If you find anything unusual, please post your findings here. Ahasuerus 19:08, 19 November 2015 (UTC)

Looks very good. Clear and precise. Thanks. Mhhutchins|talk 19:30, 19 November 2015 (UTC)

Glad to hear that it looks good! And I should have added that some editors may need to do a forced browser refresh before the new buttons work correctly. In most browsers, you can do it by pressing "Control-F5". Ahasuerus 19:37, 19 November 2015 (UTC)

Brief editing outage

Editing will be unavailable between 12:50pm and 12:53pm server (US Central) time. Ahasuerus 18:38, 19 November 2015 (UTC)

Everything should be back up. I will be posting the patch notes shortly. Ahasuerus 18:51, 19 November 2015 (UTC)

COVERART changes - Part 5 - Import/Export Contents

"Import/Export Contents" has been changed to support the new way of entering COVERART data. The "Cover Art" section is only displayed when importing a COVERART title into a pub. Ahasuerus 16:16, 20 November 2015 (UTC)

T23 and "Transmission 23"

Would anyone happen to know if T23 and Transmission 23 happen to be the same artist? Ahasuerus 14:42, 24 November 2015 (UTC)

COVERART changes - Part 6 - Edit Publication

Edit Publication has been revamped to support the new way of handling COVERART records. The software changes were significant and also affected Clone Pub, Import Content and New Pub, so please be on the lookout for bugs or any other unexpected behavior.

I believe this change makes our handling of COVERART titles consistent across the board, but I guess we'll see in the next few days. Of course, we also need to bring Help up to date. Ahasuerus 23:55, 24 November 2015 (UTC)

Thanks for writing the software for what is a major overhaul in handling COVERART entry. This revision was sorely needed, and I appreciate all of the effort that you made in doing it. I'll keep an eye out for any problems and report them here. Thanks again. Mhhutchins|talk 00:18, 25 November 2015 (UTC)

It feels good when things are finally working the way they should, doesn't it? :-) Ahasuerus 03:59, 25 November 2015 (UTC)

I've noticed that a COVERART record removed from a publication isn't deleted from the database when using the "Remove Titles" function. Was this intentional? I see no problem with this, if the record shows up on the nightly run of the Titles Without Pubs clean-up report. Should I remove one and leave it to see if it appears on tonight's report? Mhhutchins|talk 00:34, 27 November 2015 (UTC)

That's right, it was an intentional side effect of the COVERART redesign and yes, the cleanup report that you linked should include pub-less COVERART titles. I thought that making COVERART titles behave the way other types of titles behave would make everything more consistent. If the task of cleaning them up turns out to be onerous, I am sure we can revisit the issue. Ahasuerus 00:46, 27 November 2015 (UTC)

No. I agree the behavior should be consistent. I don't think it should be hard to clean-up the publess COVERART titles. Mhhutchins|talk 05:08, 27 November 2015 (UTC)

P.S. I have made a number of changes to the NewPub, EditPub and ClonePub Help pages. Hopefully everything looks OK. Ahasuerus 01:01, 27 November 2015 (UTC)

I've check them out. Thanks. Mhhutchins|talk 05:08, 27 November 2015 (UTC)

Re the new instructions for the Title and Date fields in the template for COVERART: Should there be a warning for editors to be cautious about editing these fields in situations where the field is actually editable? It seems inadvisable to change the title or date so that it doesn't match the publication's metadata. Is there a reason for it to be editable at all from a pub edit? I can see having the ability to edit it at title level, but not at pub level. Mhhutchins|talk 05:22, 27 November 2015 (UTC)

Yes, there is. If the cover appears in only one publication and the edit changes the publication title or date, then the COVERART record needs to be changed to match. As with other content titles that only appear in one publication, it should be editable so you are not forced to make additional edits. At one point, I put in a feature request to automatically update the COVERART record if the publication title or date was changed and the COVERART title record has only a single publication. That would be the ideal solution, but having it editable at the publication level is a step forward. In the past, with the COVERART record not being displayed at the publication level, it's something editors (even experienced) forgot about and we have a lot of disconnects like the example given in the feature request. A warning message on submission that the COVERART record and the publication title don't match (at least for the title) would be nice as well. -- JLaTondre (talk) 13:29, 27 November 2015 (UTC)

Thanks for the clarification. I misunderstood that the field was editable in every pub edit. Since it's only editable when there's only one publication associated it, the help documentation should be clarified. And I agree that there should be a moderator warning message for mismatched or non-standard COVERART titles. Mhhutchins|talk 18:25, 27 November 2015 (UTC)

Sounds good, I'll add it to the list. Keep in mind that we already have a cleanup report that finds COVERART titles which do not start with "Cover: ". The first time it ran, it found 10 or 12 invalid COVERART titles. Ahasuerus 20:24, 27 November 2015 (UTC)

In fact, an editor should get a warning before submission if they remove or change the "Cover: " part of the title. Mhhutchins|talk 18:25, 27 November 2015 (UTC)

That's already in place in EditPub and ClonePub. Come to think of it, I should probably add a similar pop-up message to Edit Title. Ahasuerus 20:24, 27 November 2015 (UTC)

Or even better, why not disallow that part of the title to be editable since the software automatically adds that to titles upon creation? Mhhutchins|talk 18:25, 27 November 2015 (UTC)

I am afraid it's not possible to make just one part of a field ineditable. Ahasuerus 20:24, 27 November 2015 (UTC)

Wikimedia Image Linking

I have updated ISFDB:Image linking permissions as the section on Wikimedia was woefully out-of-date. Wikimedia does allow hotlinking, but requires that the licensing conditions be met. The current ISFDB image source statement (ex. "Cover art supplied by Galactic Central") would probably not meet that requirement. I added advice on downloading the Wikimedia image and uploading to ISFDB with the proper licensing.

Wikimedia images are subject to more churn (renaming, deletion, vandalism, etc.) than our other sources. That might make it not worth including as a linking source. However, if we wished to reduce our disk space use, we could implement linking with a Wikimedia specific image source statement (something along the lines of "Cover art supplied by Wikimedia. See license for attribution." where "license" also being a link to the Wikimedia image page would probably be sufficient).

I'm not really advocating for it. I'm just pointing out the possibility since Wikimedia has changed their policy since that section of the image linking permissions page was originally written. -- JLaTondre (talk) 16:09, 28 November 2015 (UTC)

Inconsistency in display

I noticed something the other day that I'd never noticed before in this record. The first work's type is capitalized (which I really like) while the second one isn't. Is it possible to make other container types displayed the same? This would be quite helpful in OMNIBUS records, such as this one where it would be easy to see where one of the collections ended and the other began. Mhhutchins|talk 18:44, 3 December 2015 (UTC)

The way it currently works is as follows:

• The database stores all title types in all-uppercase, e.g. "COLLECTION", "NOVEL" or "NONFICTION".
• The publication display page converts most title types to lowercase, hence "collection", "novel", etc.
• The publication display page doesn't convert NONFICTION, probably because we originally thought that a NONFICTION publication would typically contain only one NONFICTION title.

It would be very easy to change the display logic not to change the case of container titles. I assume we are talking about COLLECTION, ANTHOLOGY, and OMNIBUS, right? Ahasuerus 19:34, 3 December 2015 (UTC)

Yes, but I would include NOVEL when it appears in a COLLECTION, ANTHOLOGY, or OMNIBUS, like in this publication. I'm not sure how it would look in a NOVEL publication which contains other content records when the title reference record is normally displayed. Can an exception be made if a NOVEL appears in a container publication? Also, since an OMNIBUS can't contain an OMNIBUS, I don't think it would need to be changed (unless it's easier to rewrite the display of all in a single change.) Mhhutchins|talk 20:08, 3 December 2015 (UTC)

I can see how it would be useful to distinguish between book-length titles and shorter titles in the Contents section, but I am not entirely sure that displaying title types in uppercase would be the best way to accomplish it. Whenever I see a title type appear in uppercase, my first reaction is that there is some kind of publication-title mismatch. Granted, it may be just a personal quirk, but have you considered other alternatives like making title types appear "bolded"? Ahasuerus 22:28, 3 December 2015 (UTC)

I see your point, so maybe capitalization isn't the way to go here. Still, it would be nice to see consistency as well as distinction in displaying book-length titles in the contents section. Does anyone in the group have a better idea? Mhhutchins|talk 22:54, 3 December 2015 (UTC)

Maybe add a span which adds a pastel background color to each entry (or to some of them), with specific colors for each type of entry (similar to this, but with more pastel colors so it doesn't look horrible). For example:

• ix • Foreword (Songs of a Dead Dreamer and Grimscribe) • essay by Jeff VanderMeer
• Songs of a Dead Dreamer • (1985) • collection by Thomas Ligotti
• 3 • The Frolic • (1982) • shortstory by Thomas Ligotti
• 19 • Les Fleurs • (1981) • shortstory by Thomas Ligotti
• 27 • Alice's Last Adventure • (1985) • shortstory by Thomas Ligotti
• 45 • Dream of a Mannikin • (1982) • shortstory by Thomas Ligotti
• 72 • Drink to Me Only with Labyrinthine Eyes • (1982) • shortstory by Thomas Ligotti
• 82 • Eye of the Lynx • (1983) • shortstory by Thomas Ligotti
• 91 • Notes on the Writing of Horror: A Story • (1985) • novelette by Thomas Ligotti

There could be a legend at the top showing each color and what it means, for those who don't intuitively figure it out. ···日本穣 · 投稿 · Talk to Nihonjoe 22:28, 13 December 2015 (UTC)

I personally am not fond of coloring for distinction, and it would do nothing to help the color-blind among us. And distinguishing novelettes and short stories seems to be taking it one step further than necessary. Why not use bold font for the title itself? That way you can leave the type of container ("essay", "collection","shortstory", "novelette", etc.) in the same font, e.g.:

• ix • Foreword (Songs of a Dead Dreamer and Grimscribe) • essay by Jeff VanderMeer
• Songs of a Dead Dreamer • (1985) • collection by Thomas Ligotti
• 3 • The Frolic • (1982) • shortstory by Thomas Ligotti
• 19 • Les Fleurs • (1981) • shortstory by Thomas Ligotti
• 27 • Alice's Last Adventure • (1985) • shortstory by Thomas Ligotti
• 235 • Vastarien • (1987) • shortstory by Thomas Ligotti
• Grimscribe: His Lives and Works • (1991) • collection by Thomas Ligotti
• 253 • Introduction (Grimscribe: His Lives and Works) • (1991) • essay by Thomas Ligotti
• 255 • The Last Feast of Harlequin • [Cthulhu Mythos] • (1990) • novelette by Thomas Ligotti

That would seem to distinguish container types from contained types, which may be closer to my original concern. Mhhutchins|talk 03:05, 14 December 2015 (UTC)

An interesting point. That's what Bill Contento did in his bibliography, e.g. see how The Menace of the Machine [from Erewhon] is displayed. Ahasuerus 04:18, 14 December 2015 (UTC)

The bolding would be fine, too. ···日本穣 · 投稿 · Talk to Nihonjoe 16:58, 14 December 2015 (UTC)

It would probably make the most sense to add span entity enclosures with class atrributes and then have a CSS stylesheet to control the rendering. We could make this default to bold or different fonts but this way the user could locally override the stylesheet and present it differently locally (we could also perhaps add user options to choose one of a number of premade defaults and/or let user edit their own online, not unlike how MediaWiki allows such: see MediaWiki:Manual:Interface/Stylesheets). Uzume 21:07, 7 January 2016 (UTC)

Server slowdown

FYI, the fact that the server was very slow between 3:55pm and 4:15pm was caused by a drastic increase in the number of users who were simultaneously accessing ISFDB. I have seen it happen before, but I am not sure what's causing these spikes. Ahasuerus 22:22, 4 December 2015 (UTC)

Progress report

From the list of "Most Popular Tags in the Database" as of 5 minutes ago:

• post apocalypse (666), dystopia (666)

Ahasuerus 22:01, 9 December 2015 (UTC)

I think I hear the Four Horsemen coming over the horizon. Mhhutchins|talk 22:10, 9 December 2015 (UTC)

Mind Partner

For this pub, which is verified I noticed that the artist is given as uncredited with no visible signature. That's true for the scan, but my copy has a visible signature in the lower right corner - it could be A. Sala, or O. Salio, or something like that. You can see a rather poor quality image that shows it here. I can't find any name in the database that seems to match the artist, and I didn't want to just add a note since it's a verified publication. What's the right thing to do? Mike Christie (talk) 17:26, 13 December 2015 (UTC)

ISFDB etiquette requires that you first discuss any substantial changes to records with any primary verifiers. Adding a cover art credit is substantial. Adding a note isn't. You can update the record to add the data that the signature is visible on some copies. It would be a courtesy to post a message on the talk pages of the primary verifiers, directing them to this message. Mhhutchins|talk 19:02, 13 December 2015 (UTC)

Done; thanks. Mike Christie (talk) 02:07, 14 December 2015 (UTC)

Another bug squashed

Bug 420 has been fixed. It could cause author-specific data (URLs, birth dates, etc) to be lost under certain uncommon circumstances. Ahasuerus 23:46, 13 December 2015 (UTC)

Additional title type validation added

We have run into problems with new editors using Google Translate versions of our Web pages to create invalid submissions, so I have added extra safeguards to ensure that all submitted title types are valid. If you encounter any issues when adding new publications or editing titles/pubs, please post them here. Ahasuerus 16:01, 13 December 2015 (UTC)

That will likely also help with bot submission validation too. 20:49, 12 January 2016 (UTC)

Editing pending submissions

Would it be possible to allow editing of pending submissions by the submitter? It would require the submission be locked while it was being edited so a moderator couldn't come along and approve it while it was being edited. This would allow small mistakes (or even beig ones) to be corrected rather than having to cancel a submission and then resubmit it. It would also allow for moderators to send it back to the submitter for corrections, if needed, thus avoiding extra work by having to re-enter everything just to correct something to make the submission acceptable. ···日本穣 · 投稿 · Talk to Nihonjoe 06:44, 13 December 2015 (UTC)

That's basically Feature Request 21. It's doable, but would require a fair amount of work. Ahasuerus 14:12, 13 December 2015 (UTC)

Aha. It would be a really helpful addition, I think. Appreciation in advance when you get around to it. :) ···日本穣 · 投稿 · Talk to Nihonjoe 22:15, 13 December 2015 (UTC)

Incidentally, the locking would not be that hard, moderators can already put submissions "on hold". Then users could sort of self moderate their submissions (well everything but accept/commit them of course). This type of feature might also help situations where submissions get approved out of order (e.g., submission n requests "content a" be added to the note field and submission n+m requests "content b" be added to the note field; currently there is no good way to merge these submissions and results depend on the acceptance order). There can also be race conditions if moderators are approving submissions at the same time (mod a clicks an accept link and before the server completes the transaction mod b also clicks a different accept link; often this is not a big deal but if the submissions overlap at all bad things can occur). Uzume 21:19, 7 January 2016 (UTC)

I have added a number of safeguards over the last few years, but, unfortunately, it's true that "race conditions" may still occur under certain circumstances. Ahasuerus 00:40, 8 January 2016 (UTC)

There are also order dependencies that are painful. I have had a number of submissions rejected where the rejection notice essentially tells me to do something else first only to have that approved in another (already queued) submission a short while later (I just had one like that today; albeit part of that was caused by the errored out submission I had to fixup later) so I have to rebuild the submission. Unfortunately I cannot control the order moderators look at my submissions. Uzume 05:11, 8 January 2016 (UTC)

Scheduled ISFDB downtime - 8:30pm server time

The database will be unavailable between 8:30pm and 8:35pm server time. A new patch will be installed during that time. Patch notes will be posted around 8:45pm. Ahasuerus 02:05, 17 December 2015 (UTC)

Everything is back up. Ahasuerus 02:35, 17 December 2015 (UTC)

Translation changes

As per FR 830, the way translations appear on Summary Bibliography and Series pages has been changed. Unregistered users are now able to see all translations. The User Preferences page has been changed to let registered users decide whether they want to see "All", "None" or "Selected" translations. The page formerly known as My Language Preferences is now known as "My Translation Preferences". It has been modified to let users deselect "English".

The next step is to let unregistered users select whether they want to see translations. Ahasuerus 02:54, 17 December 2015 (UTC)

Done. I have also tweaked the way non-English canonical titles are displayed on Series pages.

I believe the new behavior matches what we discussed a few months ago. If you see any inconsistencies or other problems, please post your findings here. Ahasuerus 18:18, 19 December 2015 (UTC)

Seiun Award categories

Currently, there is only the "Best Japanese Long Story" category. I need the following added:

• Best Japanese Short Story
• Best Translated Long Story
• Best Translated Short Story
• Best Artist
• Best Nonfiction (this is for nonfiction about science fiction, fantasy, etc.)
• Special Award

Thanks! ···日本穣 · 投稿 · Talk to Nihonjoe 08:00, 24 December 2015 (UTC)

Done.

Thanks, Chavey (had to look in the history since no sig). ···日本穣 · 投稿 · Talk to Nihonjoe 06:21, 26 December 2015 (UTC)

Oops, sorry. Chavey 17:38, 26 December 2015 (UTC)

Please add at least one award to each category. If you don't they may be deleted because they'll show up on a clean-up report. Thanks. Mhhutchins|talk 05:32, 27 December 2015 (UTC)

At this moment there are two empty categories: Special Award and Best Nonfiction. Mhhutchins|talk 05:50, 27 December 2015 (UTC)

The only one right now is the Special category. I'll see about adding one to it. ···日本穣 · 投稿 · Talk to Nihonjoe 19:59, 28 December 2015 (UTC)

Okay, added all winners of the Special award. Just waiting for them to be approved. ···日本穣 · 投稿 · Talk to Nihonjoe 20:47, 28 December 2015 (UTC)

Advice requested on listing an adaptation

The title Le Trasformationi di M. Lodovico Dolce is listed by WorldCat, and many other sources, as a translation of Ovid's Metamorphoses. It appears that it is more of an "adaptation" than a translation. The bookstore Librairie Ancienne J.-Marc Dechaud (France) writes: "New edition, a completely revised free translation of Ovid's Metamorphoses by Italian poet Lodovico Dolce. It is more an adaptation than a translation, Dolce is satisfied using discussions with different fables than the 'Metamorphoses', creating a new version in Italian verse, far removed from the original text of Ovid. The first edition, printed in 1553 had drawn criticism from G. Ruscelli." (French text below) He also notes that Ovid's name, which appeared on the title page of the 1553 edition, was removed from the 1555 edition, so the text credits only him. Reprint editions also omitted Ovid's name until the 1568 & 1570 editions, after Dolce's death (which add "Tratte da Ovidio"). The English Wikipedia page for Dolce describes this title as a translation, but the Italian Wikipedia page calls it an adaptation (adattamento).

Presumably, I need to revise a bit how we list that title here. But do I list this title as a separate adaptation book by Ovid & Dolce? Should the 1555-1561 printings be listed "by Ovid & Dolce [as by Dolce]"? And if your French is better than mine, how do I interpret the last sentence in the "Librairie Ancienne" description, which I did not translate above? Chavey 20:38, 28 December 2015 (UTC)

Librairie Ancienne J.-Marc Dechaud: "Nouvelle édition, entièrement refondue de la traduction libre des Métamorphoses d'Ovide par le poète italien Lodovico Dolce. Il s'agit plutôt d'une adaptation que d'une traduction, Dolce s'étant contenté d'utiliser les arguments des différentes fables des Métamorphoses pour en faire une nouvelle rédaction en vers italiens, très éloignée du texte original d'Ovide. La première édition, imprimée en 1553 s'était attiré les critiques de G. Ruscelli. L. Dolce reprit entièrement son travail et publia cette nouvelle édition en 1555, en prenant soin de ne plus faire apparaître le nom d'Ovide sur le titre.").

It seems sad that adapters (e.g., all the zombie derivatives of more famous works) get credited here but translators (some have even won translation awards!) do not. Uzume 20:46, 12 January 2016 (UTC)

Script to export all primary verified records to Book Catalogue (Android app)

If anyone is using or interested in using the Book Catalogue app for Android and wants to have all currently primary verified pubs in that app as well: I wrote a big SQL which does a one-time export of the primary verified records from a local copy of the ISFDB database to the Book Catalogue import/export format.

I documented all steps I needed to export the data on my page just in case someone else is interested: One-time export of primary verified records to Book Catalogue

Jens Hitspacebar 16:49, 30 December 2015 (UTC)