ISFDB:Community Portal/Archive/Archive32

Jump to navigation Jump to search

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

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

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

Archive of messages from January - April 2014

Nicholas Sparks

I'm in the process of deleting this author from the db. All of the records here were either NONGENRE, or non-sf-related NONFICTION. Mhhutchins 19:26, 2 January 2014 (UTC)

Emails of new editors

How was an editor able to create an account without providing an email? I tried to contact one (98Nascar) who has started uploading cover images, but isn't aware that they have to be manually linked to the pub records. I thought the new sign-up process required an email address. Or was I wrong? Mhhutchins 00:07, 3 January 2014 (UTC)

Could be repeat of ISFDB:Moderator noticeboard#User email contact. -- JLaTondre (talk) 00:57, 3 January 2014 (UTC)
What is in the email message that we're sending new users in the registration process? I'd really like to see if perhaps we should be giving them more information, as it's obvious most of them have a hard time finding their user talk page. Mhhutchins 01:15, 3 January 2014 (UTC)
The Wiki software sends a canned e-mail message with a link back to the Wiki page which the user needs to follow in order to register. Here is what it looks like:
  • Someone, probably you, from IP address NNN.NN.NN.NNN, has registered an account "TestAccount" with this e-mail address on ISFDB.
  • To confirm that this account really does belong to you and activate e-mail features on ISFDB, open this link in your browser:
  • If this is *not* you, don't follow the link.
  • This confirmation code will expire at 04:09, 2 June 2013.
Ahasuerus 04:26, 3 January 2014 (UTC)
So is it possible to add a note that provides basic information, like links to the Help pages and their User Talk page, etc? Mhhutchins 05:07, 3 January 2014 (UTC)
I don't think we can do it with our version of the Wiki software. There is an extension, which seems to do what we want to do, but I will have to review it to see if we have the necessary prerequisites. Also, it may be easier to change the "You Have New Messages" warning to appear at the top of the page in big yellow letters -- I'll take a look tomorrow. Ahasuerus 06:26, 3 January 2014 (UTC)
It turns out that the extension linked above doesn't do what I thought it was supposed to do: it notifies a subset of Wiki administrators when new users sign up, but it doesn't let you customize the welcome message. Oh well. I will try to change the "New Messages" behavior tomorrow. Ahasuerus 04:18, 4 January 2014 (UTC)
A more prominent MESSAGES HAVE BEEN LEFT ON YOUR TALK PAGE notice should help, along with a link. Hopefully a link that doesn't go into edit mode like the current one! Thanks. Mhhutchins 04:28, 4 January 2014 (UTC)

Award categories: "Best Novel" vs. "Novel"

Our awards are often confused as to whether an award category should be listed as "Best Novella" or just "Novella". The Locus Award pages essentially always omit the word "Best". Wikipedia fairly uniformly includes it. We have no policy. This means that award categories often depend on who entered the award, and we have 9 awards where the use of that term varies from year to year. (Analog Award, Aurealis Award, British Fantasy Award, British Science Fiction Award, Hugos, Retro Hugo Award, Locus Poll Award, Nebulas, and World Fantasy Award.) I've even seen some cases where in the same year the winner was under one name, and the nominees were under another, or some nominees were under each name. It seems to me that we should standardize on one form of these names or the other. I don't really care which, I just think we should select one form and go with it. Chavey 22:55, 4 January 2014 (UTC)

It sounds like a good idea. The plan is to convert award categories to an award-specific drop-down list, so the more uniform these categories are across years, the easier the conversion will be. Ahasuerus 16:21, 5 January 2014 (UTC)
Any preference as to which version we standardize on? Chavey 23:45, 6 January 2014 (UTC)
I guess the first question to answer is "Are there situations where the short version, e.g. "Novel", may be ambiguous?" I can't think of any, but perhaps I haven't considered some obscure cases. Ahasuerus 18:23, 7 January 2014 (UTC)

Security and Advanced Search enhancements

A few weeks ago Marty and I started working on the "major security problems" that Dirk Stoecker mentioned in one of his posts in November. The problems were indeed major and it took 60+ patches to resolve them. I think we are almost done now, although I still need to clean up some low priority areas.

Now for the good news. One of the particularly dangerous areas was Advanced Search and the underlying software needed to be revamped to eliminate various security vulnerabilities. As part of the revamp the following changes were made:

  • You can now see pages 2+ when searching on values containing Unicode characters, quotes and other punctuation characters. Backslashes are still not supported in searches.
  • A few spurious "Sort by" values have been eliminated, specifically "Web Page" for Authors and "Note"/"Month" for Pubs.
  • Sorting by "Image URL" has been fixed and should work correctly now although it doesn't seem to be particularly useful.
  • Advanced Author Search has been changed to display the "Last Name" field.
  • Sorting by price has been enhanced to ignore most common currencies and treat the values as numbers so that they would sort correctly. It's still not perfect because some less common currencies are not recognized, but it's no longer totally useless.
  • Sorting by page count has been improved. Again, it's not perfect because it doesn't know how to sort Roman numerals, but at least it sorts 140 after 92 now.
  • When searching by year, the YYYY restriction is no longer enforced. A search on "189" will find all titles first published in 1890-1899.

Unfortunately, given the way the database is currently organized, it's impossible to completely eliminate false positives when dealing with Unicode characters. That will have to wait until we convert the underlying data to Unicode. Ahasuerus 03:06, 6 January 2014 (UTC)

Thank you! I particularly appreciate the improvement in "search by year". I see, though, that this only applies to title searches and not to publication searches. The search also seems not to function with years beginning with "0", i.e. anything from the first millennium. So no variation of the years "0600" or "0008" will find Fulgentius' Mitologiae or Ovid's Metamorphoses. Chavey 23:59, 6 January 2014 (UTC)
Hm, let's see... <pokes the code with a stick> The problem is that we use the "YEAR" function, which only works with post-1000 dates. I'll try a different approach later today and see if it works better. Thanks! Ahasuerus 18:19, 7 January 2014 (UTC)
I have made a few changes to standardize the behavior of Year searches for titles and pubs and you should be able to search for 0YYY dates now. However, the same change disabled searching for '0000', which, upon reflection, may be undesirable. I think I need to reverse that part of the change although it will make it somewhat harder to search for pre-1000 titles. Ahasuerus 04:48, 8 January 2014 (UTC)
Another patch installed. Please give it a try to see if anything stands out. Oh, and keep in mind that year searches support wildcards now, so searching on "17*0" finds all titles published in 1700, 1710, 1720, 1730, etc. Ahasuerus 05:02, 8 January 2014 (UTC)
This appears to work correctly on my trial data. Of course there are fairly few titles listed under those dates yet, but I expect to add another half-dozen. It would be nice if someone could search books in the first millenium without getting all the "0000" dates, but I don't think it's worth losing the ability to search for "unknown" dates just to get this (fairly minor) feature. Do you expect to add this search ability for publications? That would be helpful as well. Chavey 02:45, 10 January 2014 (UTC)
Hm, I thought I made the logic behave consistently across the board. Does it not work for pubs? Ahasuerus 03:28, 10 January 2014 (UTC)
My mistake, I tested it with a title, whose year we know, but for which we don't have a publication. Further checking shows that title year searches and publication year searches are working identically. However, they are not working as you stated in your first posting, and I don't know if this is an error. For example, a search for year = "06**" brings up the two titles (and one publication), but searching for year = "06" does not. But this is consistent with later dates: Searching for "189*" brings up lots of records; searching for "189" brings up no records. Chavey 17:48, 10 January 2014 (UTC)
Sorry, that was my mistake. I kept changing the behavior when I was working on the logic and the final result didn't match what I wrote above.
Now, here is why I kept changing things. Ordinarily, the logic checks if the entered search string matches anything in the specified field, e.g. a Title search on the word "and" finds "And Not Make Dreams Your Master" as well as "Sodom and Gomorrah, Texas". That's fine and dandy, but when you enter "18" as your year value, do you really expect the logic to find a bunch of 1918 records in addition to the 18* records? The way it currently works, you will only get the 1800-1899 records; if you want the 1918 records as well, you will need to enter *18 instead. If this is undesirable or confusing, please let me know and I will change the behavior.
P.S. I should add that some fields, e.g. the "format/binding" field, check for an exact match. Ahasuerus 18:41, 10 January 2014 (UTC)

Standardizing binding codes

The "Format/Binding" field as it appears on the New Publication page has been changed from a "free text" field to a drop-down list. Please note that the last discussion of this issue kind of petered out, so I am not entirely sure that the results match the intent. If you could take a look and provide feedback, I will adjust things before I make similar changes to the other Add/Edit Pub pages. TIA! Ahasuerus 05:20, 9 January 2014 (UTC)

Looks good to me! (BTW, the field is titled "Pub Format" in the entry form.) Thanks. Mhhutchins 05:35, 9 January 2014 (UTC)
Glad to hear that it looks good! I have changed Add Pub to use the same logic, so all that's left is Edit Pub and Clone Pub. Before we do that, though, we will need to change the pubs listed by the "Uncommon Publication Bindings" cleanup script to "other". Ahasuerus 18:21, 9 January 2014 (UTC)
I started doing that a few weeks ago. There are some that remain, mostly primary verified records, but I thought the verifiers should make the change. But since none of them seem to be following this thread (or the previous one), I'll submit the changes myself. Mhhutchins 19:29, 9 January 2014 (UTC)
In the meantime I will create a database conversion program which will change all publication records without a binding code to "unknown".
As far as "Pub Format vs. Binding" goes, the field is called "Pub Format (Binding)" in our Help, so I guess "Binding" can be considered an "official alias" :) Ahasuerus 18:21, 9 January 2014 (UTC)
The final change has been applied and the field should appear as a drop-down list everywhere. Let me see if I can tweak the Help pages to reflect the new appraach... Ahasuerus 00:30, 10 January 2014 (UTC)
I'm seeing a minor issue where a record existing with a format of "Pulp" is defaulting to "unknown" when I attempt to edit the record. I presume this is because of the case of the existing record "Pulp" vs "pulp". Can we change existing records by script to normalize the case? I'd hate for the data to get lost because if someone missed that it changed while they are editing some other item in the record. --Ron ~ RtraceTalk 03:05, 10 January 2014 (UTC)
Eek, that's pretty bad. Sorry about that! Let me see what I can do... Ahasuerus 03:27, 10 January 2014 (UTC)
It turns out that we have quite a few discrepancies like that. I didn't notice them when I was changing the code because almost all of our database queries ignore case (the default behavior), so all I saw was the lowercase versions. Upon closer examination, it turns out that we have 8 "HC"s, 28 "Webzine"s, 1,743 "Pulp"s, 228 "Quarto"s and so on. The cleanup will take a little bit of time and for now I have applied a band-aid: when a publication with an incorrectly capitalized format code is edited or cloned, the software will choose the correct code from the list. Hopefully this will give us some breathing space. Ahasuerus 03:50, 10 January 2014 (UTC)
OK, I think I got them all now. No more "a5", "ebooK", etc :) Ahasuerus 04:20, 10 January 2014 (UTC)

Pseudonyms with canonical titles

I've been cleaning up this script off and on for the past month or so. It originally had almost 1000 authors, but is currently down to less than 300. In the clean-up process I discovered that the most common reason that such authors exist was that an editor had made an author into a pseudonym but failed to follow-through and create variants for each of the titles under the pseudonym. Please keep that in mind when creating pseudonyms in the future. Thanks. Mhhutchins 23:24, 9 January 2014 (UTC)

I've sometimes worked around it a bit. For the french domain, the main source is an illustrator problem. For example J.-L. Verdier & Jean-Louis Verdier are likely the same person but positive evidence is scarce, it didn't deter some editors who created pseudonymistic relations based on (IMHO and to the best of my knowledge) very flimsy data (e.g. the real person(s) behind the Christopher Stork titles). As I think that we're not primarly an illustrator database, I tend to standardize their names (e.g. by entering "Philippe Caza" even if the cover is just credited to "Caza" or "P. Caza"). Hauck 16:54, 11 January 2014 (UTC)
I agree that that would have been the best approach to handling slightly credited artwork, but sadly, that wasn't discussed or had already been decided before I started working here. I see no reason not to give the full name in art records, even if only a shortened one is used in the publication. (I even see pseudonyms and credits based on artist signatures!) At this point, it would take hundreds of hours of work to make corrections in the database according to that standard. The editors who were working on magazines were the ones who are responsible for creating all of those "pseudonyms" because they felt artist credits should be handled the same as author credits. It would have been so much easier if crediting artists would have its own standards. I wish it had been brought up for discussion before what has now become the standard. Thanks. Mhhutchins 02:26, 12 January 2014 (UTC)

Patch r2014-10 - User names with punctuation characters

User names with apostrophes, ampersands and other unusual characters should no longer result in unapprovable submissions. Ahasuerus 02:32, 10 January 2014 (UTC)

"Add Email" and "Add Web Page"

As per FR 425 and FR 513, these two buttons have been added to the Edit Author page. I hope to add them to Edit Title, Edit Publisher, Edit Pub Series and Edit Award Type shortly.

Please note that at this time you can still use semicolons to separate multiple addresses, but this functionality will be going away in the foreseeable future. Semicolons are valid (although rare) in URLs, so we really shouldn't be using them as separators. Ahasuerus 00:18, 12 January 2014 (UTC)

Edit Award Type done; rudimentary mouseover Help added. Ahasuerus 04:20, 12 January 2014 (UTC)
Edit Publisher done in r2014-17. Also fixed an old bug which could cause publisher Web pages to disappear during editing. Ahasuerus 06:51, 12 January 2014 (UTC)
Edit Pub Series done. Ahasuerus 20:29, 12 January 2014 (UTC)
Edit Title done. Also add the standard "Note to Moderator" field to Edit Review and Edit Interview plus basic mouseover Help. Ahasuerus 01:56, 13 January 2014 (UTC)

Edit Author changes and a Clone Pub fix

Edit Author has been changed to use the same kind of mouseover help that New/Add/Clone Pub pages use. In addition, Clone Pub should no longer mangle field values containing double quotes. Ahasuerus 02:54, 12 January 2014 (UTC)

Patch r2014-23 - Semicolons are no longer valid separators

As of 15 minutes ago, semicolons can no longer be used as separators in any "Email" or "Web Page" fields. Please use the "Add Email" and "Add Web page" buttons instead -- this affects Edit Title, Edit Author, Edit Publisher, Edit Pub Series and Edit Award Type.

Also, please note that this was a major patch and touched almost 20 scripts, so it's possible that new bugs were introduced. If you see anything unusual, please report your findings here. Ahasuerus 04:35, 15 January 2014 (UTC)

Good. I always forgot how to add additional entries, and had to go back to see how they were entered. Thanks for adding the "Add" fields. Mhhutchins 04:55, 15 January 2014 (UTC)

Patch r2014-25 - Web pages enhancement

Links to third party Web pages should look better now. In addition, the following sites are now recognized by the software and should be labeled appropriately:

  • Blogspot
  • Books and Writers (
  • Facebook
  • Fan Gallery (
  • FantLab (
  • Goodreads
  • Gutenberg
  • LibraryThing
  • LinkedIn
  • LiveJournal
  • Myspace
  • SFF Net
  • SFE3
  • Shelfari
  • Tumblr
  • Twitter
  • WordPress

These changes affect all ISFDB pages which display links to third party sites: Author, Title, Publisher, Pub Series and Award Type. Ahasuerus 01:56, 16 January 2014 (UTC)

The "IMDB" field has been eliminated and its values have been moved to the Web Page(s) field. Ahasuerus 05:30, 16 January 2014 (UTC)
Good thing. Will eventually the Wikipedia link also be displayed on the same line as SFE3, IMDB, and other? Or will it retain its distinction? I personally feel it should not have preferential treatment. Mhhutchins 17:58, 16 January 2014 (UTC)
Absolutely! As I wrote on the Rules page the other day, "I am currently in the process of implementing FR 361, "Merge Web pages, Wikipedia links and IMDB links; enhance their display". Once the feature has been fully implemented, the current Wikipedia and IMDB fields will be going away and multiple Wikipedia links (EN-, DE-, FR-, etc) will be supported." This will also simplify linking to multiple Wikipedia-EN pages per author, e.g. and . Stay tuned :) Ahasuerus 18:05, 16 January 2014 (UTC)

Author Tags

The changes that Ahasuerus recently made to the author data section of the summary pages has me thinking about another area that I believe needs fixing. Does anyone other than me passionately dislike the prominent display of Author Tags on an author's summary page? Sometimes they can be very distracting, as in this case. Is it possible to move these to the bottom of the page? After all, they're only one user's opinion and can't even be disputed and removed, despite another user's being more knowledgeable about the subject. There's also so many near duplicates. For example, what's the difference between a language translation device, a language translator, and a translating machine? We have "domed city", "domed cities", and "giant domed cities". I'm still waiting for the "giant glass domed city". All of this is too subjective for a database, in my opinion. Especially since only the editor who created a tag can edit or delete it. Anyone else is unable to even merge these almost identical tags. There's even a few which are misspelled, which is quite embarassing. Suvival? It has also been used to add series data to titles, like this one. (Maybe at one time that was the only way to add a title to a series?) Just look at all of the current tags, and the sheer amount is overwhelming. Some of them are not even necessary since any editor can now enter award data. Until we can fix these problems, at least as a start, I suggest that it not receive such prominent display on an author's summary page. Mhhutchins 18:11, 16 January 2014 (UTC)

I'd be more extreme than that => DELETE ! (or please make them visible only by their creators) Hauck 18:17, 16 January 2014 (UTC)
I'd like to delete the ones that are clearly destined for use by only one editor and edit/merge other nearly doublette. Also quite useful would be a search engine to find tags already invented by other editors. Stonecreek 19:42, 16 January 2014 (UTC)
There are two ways to find tags. One is to use the "Tag" option in the regular Search box. The other is to pull up the Edit Tags page for a title and select "Show All Tags" at the bottom of the page. Ahasuerus 21:02, 16 January 2014 (UTC)
It is of no major concern to me where the tags are displayed for authors (but I'd like to have them near the top for titles.) Stonecreek 19:42, 16 January 2014 (UTC)
It sounds like we have at least two separate issues here. The first one is the number of tags displayed on the Summary page, which can get overwhelming. I think that that can be addressed by limiting the number of displayed tags to 20 (?) and giving the user a way to display the rest upon request.
The other issue is making some tags "private" as requested in FR 343. Once the FR has been implemented, most of the issues listed above will disappear, although it will leave the issue of duplicates and misspellings open. It's certainly possible to let moderators edit/merge tags, but we'll have to consider the side effects first. Ahasuerus 21:02, 16 January 2014 (UTC)

Wikipedia field is no more

The "Wikipedia link" field has been eliminated with extreme prejudice. In the future, please enter all third party URLs for authors, titles, award types, publishers and publication series in the repeating "Web Page" field.

In addition, the software has been upgraded to label Wikipedia URLs "Wikipedia-EN", "Wikipedia-FR", "Wikipedia-DE", etc as appropriate, e.g. see the way Jules Verne's and Boris Strugatsky's Summary pages appear now. Also, if an author has more than one linked page/URL hosted by the same site, the software displays them as "XYZ-1", "XYZ-2", etc, e.g. see Andre Norton's page. Ahasuerus 06:32, 17 January 2014 (UTC)

ISBN display

We currently display two ISBN lines on the Title page, one for ISBN-10 and one for ISBN-13. How about we add the words "(actual)"/"(derived)" to each line? Ahasuerus 22:28, 17 January 2014 (UTC)

We only display the stated ISBN on the title page. It's the publication page which displays both without indicating which one is stated. :) Mhhutchins 02:56, 18 January 2014 (UTC)
Oops! :) Ahasuerus 04:34, 18 January 2014 (UTC)
It would be nice to have some indication as to which was the underlying entered one. I've been caught up a couple of times when I've verified a publication on the displayed record and forgot to check the ISBN via editing the record. -- JLaTondre (talk) 23:03, 17 January 2014 (UTC)
If given a choice, I'd rather that only the stated one would be displayed in the pub record, as it is now under the title record. Is there any benefit "derived" from giving both ISBNs? But if we have to have both, perhaps "Stated" would be a better description. Both of them are actually ISBNs. So a publication with an ISBN-10 would have "Stated ISBN-10" and "Derived ISBN-13", and one with an ISBN-13 would have "Derived ISBN-10" and "Stated ISBN-13". Mhhutchins 02:54, 18 January 2014 (UTC)
As I recall, the last time we had this discussion, a number of editors thought that displaying both ISBNs would be useful. Since it's easy to add "Stated" and "Derived", let me do that first and then we can see if further tweaks are needed. Ahasuerus 04:34, 18 January 2014 (UTC)
Done. I am not sure I like the way it looks, but I can't think of a more intuitive way to convey the same idea. Ahasuerus 05:09, 18 January 2014 (UTC)
I agree. It doesn't look well. I'm still not sure why we have to display both. What was the argument presented by those who wanted both displayed? Mhhutchins 06:12, 18 January 2014 (UTC)
I don't particularly care for it, either. One benefit of showing both, though, is that other lists in the wild may use the derived ISBN, and anyone not familiar with ISBNs in general or with the functioning of the check digit in particular may not recognize that the derived ISBN in fact is just a different way of displaying the stated ISBN unless they're shown the derived ISBN. Whether that's a big deal or not, I do not claim to know. But... What if we just had one ISBN line, showing Catalog #/ISBN (aside: display uses Catalog ID but entry uses Catalog #), and when it's an ISBN either put the derived one after, in brackets or parens, or always list them 10 followed by 13 but adorning the one that's derived. Note that using brackets would at least be consistent with our convention for "derived" page numbers. We could do this just about everywhere an ISBN is displayed, if we wanted to.
•Publication: Engines of Destiny 
•Authors: Gene DeWeese
•Year: 2005-03-00 
•ISBN: 0-671-03702-1 [978-0-671-03702-4]
•Publisher: Pocket Books 
•Price: $7.99 
and either
•Publication: Scarecrow Returns
•Authors: Matthew Reilly 
•Year: 2012-12-26 
•ISBN: 978-1-4165-7760-7 [1-4165-7760-2] 
•Publisher: Pocket Books 
•Price: $7.99 
•Publication: Scarecrow Returns
•Authors: Matthew Reilly 
•Year: 2012-12-26 
•ISBN: [1-4165-7760-2] 978-1-4165-7760-7 
•Publisher: Pocket Books 
•Price: $7.99 
for example. I suppose if the bracketed form were not always last, a comma separator and/or alternate font face or shading might be a good idea. --MartyD 11:50, 18 January 2014 (UTC)
If we have to have both (and I'm still not convinced that we do), the one line approach is much better. OCLC does it without brackets, but always gives the stated ISBN first, followed by the derived one. Amazon gives them on two lines, labels them, with the 10 first, and without indicating which one is stated. That's why there are still editors (and moderators) entering ISBN-10s on books from the past 7 years when using Amazon as the source. Still wish there was a way to indicate which ISBN appears in the book, but isn't as inelegant as the current labeling. Of the two choices Marty presents here, I prefer the first (giving the stated ISBN first followed by the derived one in brackets). Mhhutchins 16:11, 18 January 2014 (UTC)

(unindent) Good points all over the place! :-) Based on the suggestions above, I have combined the two ISBN lines. The "stated" ISBN should be displayed first while the "derived" ISBN appears next to it, pre-shrunk and in square brackets. How does it look? Ahasuerus 21:12, 18 January 2014 (UTC)

Looks great. I like it smaller as well as bracketed. Thanks. Mhhutchins 21:36, 18 January 2014 (UTC)
We might wish to modify the Edit Pub pages so that after the ISBN field there is a set of three radio buttons "Stated ISBN .... Derived ISBN .... Uncertain", with "Uncertain" as the default. Chavey 07:09, 19 January 2014 (UTC)
That would be unnecessary. The software derives the other ISBN automatically. And there's nothing uncertain about it. You can only enter one ISBN which the system assumes is the stated one, and it does the rest. If you're working from a secondary source, follow this simple rule: enter ISBN-10s for books published before January 2007 and enter ISBN-13s for those published in January 2007 and after. It's not perfect but it will work until a primary verifier comes along. OCLC will tell you which one is stated (the first one listed.) Amazon will not unless the book has a "Look Inside". Some British publishers started using them starting in 2005, when the change was initially proposed, but publishers weren't required to use them until January 2007. Even then there were stragglers, especially in small press and self-published books. That's why the clean-up script looks for pubs before 2005 (December 2004 and earlier) and after 2007 (January 2008 and later). Mhhutchins 18:28, 19 January 2014 (UTC)

Summary page and tags

The way tags are displayed on Summary pages has been changed. If an author has more than 20 tags associated with him or her, only the first 20 are displayed. The rest can be seen on a separate page, e.g. see the way Kim Stanley Robinson's and Robert A. Heinlein's Summary pages appear now. Ahasuerus 15:03, 18 January 2014 (UTC)

Much better. That solved one of the problems with tags. Thanks. Mhhutchins 16:26, 18 January 2014 (UTC)
Added a link from the new Author Tags page, which was kind of a dead end, back to the Summary Bibliography page. Ahasuerus 21:09, 18 January 2014 (UTC)

Margaret Atwood

We have a large number of books by Margaret Atwood that are listed as genre which, so far as I know, have no speculative fiction elements. (I do not include someone thinking they've seen a vision of the Virgin Mary as speculative fiction.) The books I question are: Surfacing, Lady Oracle, Life Before Man, Bodily Harm, and Cat's Eye. None of these are included in the "standard" lists of speculative fiction by her. The Wikipedia pages on these books mention nothing that would imply they have speculative elements. None of our title records include any "Title Summary" information that indicate any speculative fiction elements. And Atwood, who has discussed her use of speculative fiction in some detail, does not include any of these books in those discussions. Consequently, I am converting them all to "Non-Genre" status. If you think this is inappropriate for one or more works, please change them back to "Novel"s, but include something in the Title Summary as to what the speculative elements are. Chavey 02:30, 20 January 2014 (UTC)

Series enhancements: Web pages and Notes added

Effective immediately, you can add Web pages and Notes to series. If everything looks good over the next couple of days, we can start moving series-specific comments from the Wiki to the database. Ahasuerus 04:07, 20 January 2014 (UTC)

P.S. A few other enhancements were implemented at the same time, including additional mouseover Help and a better way to view the data that you have just submitted. Ahasuerus 04:08, 20 January 2014 (UTC)

P.P.S. Please note that the newly added fields do not appear on the "Issue Grid" page at this time. They probably should -- I will work on it tomorrow. Ahasuerus 05:58, 20 January 2014 (UTC)

Done. Ahasuerus 23:46, 20 January 2014 (UTC)

"Percent of Novels in Series by Year"

By popular demand (or at least based on numerous Usenet discussions), a new report, Percent of Novels in Series by Year, has been added to the ISFDB Statistics and Top Lists menu.

The trend is not exactly surprising, but it's interesting that the last 10 years worth of data points are somewhat uneven. I suspect that the numbers will go up once we clean up 2004-2005 when our raw data was particularly dirty. Ahasuerus 01:57, 21 January 2014 (UTC)

The report has been modified to show short fiction works in addition to novels. It may not look like a big change, but this is our first graph to use multiple lines as well as colors, which opens the door to bigger and better things in the future :) Ahasuerus 05:04, 23 January 2014 (UTC)

Private tags implemented

Private tags have been implemented. If you enter the word "read" in the search box and run a "Tag" search, you will see that most of the 72 tags which include the string "read" ("read horror", "to read 1960s", etc) are now marked "private". If you follow the link to one of these newly private tags, e.g. "read", you will note that it says "This tag is currently marked Private" at the top of the page. (Moderators will also see a button which lets them change tag status from public to private and back.)

The important thing is that private tags should only appear on the Summary and Title pages if the viewing user has used this tag for this author/title. Everyone else will see a list limited to public tags.

In addition, the "User Tag" page has been enhanced to show tag status and its format has been made more user-friendly, e.g. see Dgeiser13's Tag page. You can view other user's private tags by following the link in the "Count" column.

We still need to decide what to do about misspelled and duplicate tags, but hopefully this will address the most pressing need. Ahasuerus 18:13, 21 January 2014 (UTC)

Fantastic! I bow in awe that you make dreams come true! Thanks, Stonecreek 19:24, 21 January 2014 (UTC)
I am here to serve Man! :-) (Well, other carbon-based species too as long as they are a good source of protein.) Ahasuerus 19:52, 21 January 2014 (UTC)
Nice! Now to get rid of those award based tags. Thanks. Mhhutchins 20:36, 21 January 2014 (UTC)

Double spaces in titles

It turns out that Bug 327, "Pub Edit approval mishandles contents titles with colons", is more complicated than it looks. The underlying problem is that some title records (2570 at last count) contain anywhere from 2 to 7 adjacent spaces. Because of the way HTML works, these adjacent spaces are displayed as one space on regular (but not on "edit X") ISFDB pages, so you normally do not notice them unless you search for " " using the regular search box. To make things even more confusing, most (but not all) edit pages automatically replace two (but not three+) adjacent spaces with one space when they display the edit form, which is what prompted the original bug report.

I can't think of any reason to allow adjacent spaces since they can not be seen on HTML pages. Moreover, they make searches fail because a search on "one and two" will fail to find "one and two". I propose that we change the software so that adjacent spaces would be automatically replaced with a single space at submission creation time. Thankfully, it will be a simple change because all submitted data is processed in one place, although we will also need to change some edit pages. Would that be OK? Ahasuerus 20:09, 21 January 2014 (UTC)

Yes. Fine with me. Removing the extra space at the time of the original submission would be best. I'm often fooled when I'm working on a submission to update a pub record, and there are fields shown to have changed, but the change isn't visible. This more often than not occurs when a user has entered two spaces after a colon (other other punctuation mark) upon its original entry (like user Biomassbob), which doesn't get "fixed" until after the pub record is updated. Will those 2750 titles have to be manually corrected? If so, is a script necessary, or would Advanced Search find them? Mhhutchins 20:44, 21 January 2014 (UTC)
I am 99% sure that I can write a script that will correct the affected titles automatically. Ahasuerus 00:01, 22 January 2014 (UTC)
The software has been updated and the data has been cleaned up. I think this takes care of everything, but I guess we'll find out soon enough. Ahasuerus 03:41, 22 January 2014 (UTC)
Thank you! Chavey 12:12, 22 January 2014 (UTC)
I've noticed that newlines now appear to be stripped out in the publication notes field which sounds like it may be related to the above change. While I realize that the whitespace doesn't matter as far as display of the notes, I do think it is valuable when one is editing existing notes, e.g. finding the list item you want is easier when each starts on a new line. Would it be possible to restore newlines and other whitespace to notes fields? Thanks. --Ron ~ RtraceTalk 13:45, 22 January 2014 (UTC)
Can you link to a pub record in which that's happened? Looking at my verified records, I could find none in which the spaces between lines were removed (i.e. one line butting against another) in edit mode. And I use both HTML breaks and HTML lines. BTW, I'm not sure what a "newline" is, so I don't use them when entering notes. Perhaps that's the reason the change did not affect any of my notes? Mhhutchins 16:50, 22 January 2014 (UTC)
I just looked up newline, and understand that it's the equivalent of using the typewriter carriage return or the keyboard "enter" key. I only use the "enter" key in editing pub notes to start a new line after an HTML break or to start new HTML line in edit mode. I've advised new editors not to use it as well. Is that the reason for what's happened to your notes? Mhhutchins 16:54, 22 January 2014 (UTC)
I'm not certain that we're precisely talking about the same thing. I'm just referring to starting comments on new lines in the notes field in order to make it easier to read when editing. It has no effect on the display of the notes. Also, notes entered before the change have not had these newlines removed, only those that have been edited recently. An example with the newlines separating content is here. Whereas when I cloned the same note as a basis for this note, the newlines were stripped when the edit was submitted/approved. Note that the display on both is identical, but when editing the note, the former is easier to read and edit than the latter. --Ron ~ RtraceTalk 18:23, 22 January 2014 (UTC)
So they only disappear when you create a new record? Hopefully, it can be corrected, and we can eat our cake and have it, too. Thanks. Mhhutchins 18:39, 22 January 2014 (UTC)
Actually I think it happens on an edit to the note field in an existing record, which is the only scenario where I've observed it. I assume it would occur on a brand new record as well. --Ron ~ RtraceTalk 18:53, 22 January 2014 (UTC)
You're right. It happens after you edit the note field of any record. I just tested it. I can see why that would be disconcerting if you come back to update it later. Hopefully, it can be fixed. Thanks for catching that byproduct of another fix. Mhhutchins 18:58, 22 January 2014 (UTC)
Hm, sounds like an unintended side-effect. I need to run out to take care of Real Life (tm), but I'll take a look later tonight. Ahasuerus 19:15, 22 January 2014 (UTC)

(unindent) OK, I think I have fixed the problem with Notes (and the pub linked above.) Sorry about the aggravation -- always something... Ahasuerus 01:45, 23 January 2014 (UTC)

Thanks. It looks good. It wasn't that aggravating and I certainly understand the reason for the original change. Thanks for addressing it so quickly. --Ron ~ RtraceTalk 02:35, 23 January 2014 (UTC)
Well, I was the one who broke it, so the least I could do was fix it :) Ahasuerus 05:02, 23 January 2014 (UTC)

Changes to webpages field display are brilliant!

Listing the website (rather than the entire link) and allowing multiple entries in the same session are great changes. In my case this change is especially valuable for entering webpage data in the title records.--swfritter 21:58, 21 January 2014 (UTC)

Glad it's proved useful :) Ahasuerus 23:40, 21 January 2014 (UTC)

"You have new messages" changes

The "New messages" notification has been changed to appear at the top of the page. It contains more specific instructions on how to respond and uses a bigger font, so hopefully new editors won't be able to miss it. (The old notification is still displayed in the navbar.) Ahasuerus 00:00, 22 January 2014 (UTC)

Can you leave a message on my talk page so that I can see what the notification looks like? (I tried to do it myself, but I guess the system frowns on I mean self-notification.) Thanks. Mhhutchins 17:23, 22 January 2014 (UTC)
Based on Michael's feedback, the background color has been changed to bright yellow (you may need to hit Ctrl-F5 to have the browser refresh its cache) and the link now points to the main Talk page rather than to the "current-vs-last diff" page. If any new editors still fail to notice the message, they are probably comatose :) Ahasuerus 01:13, 23 January 2014 (UTC)
P.S. BTW, an editor can set up more than one account using the same e-mail address. I used "TestAccount" to test the last round of anti-spam measures and, of course, I also run Fixer, so I have three accounts, which makes it easy to test these kinds of things. Ahasuerus 01:13, 23 January 2014 (UTC)

Database editing outage

Database editing will be disabled for about 5 minutes effective 6:50pm server time. Ahasuerus 00:47, 22 January 2014 (UTC)

Done. Ahasuerus 00:54, 22 January 2014 (UTC)

Patch r2014-58 - Additional language enhancements

The way languages are handled has been changed in two ways.

First, if the language of a variant title is different from the language of the canonical title, the former is now displayed on the author's/series' Bibliography page. (Of course, you will only see the languages selected under "My Preferences"/"My Languages".)

Second, if the language of a canonical title differs from its author's "working language", the former is displayed on the author's Summary Bibliography page. This is helpful when dealing with translated collections and omnibuses with no analog in the author's working language, e.g. see Le géomètre aveugle, a collection of French translations of Kim Stanley Robinson's stories, or various Dutch, French, Italian and German collections/omnibuses of Philip K. Dick's stories. Please note that this doesn't work on Series Bibliography pages because a series doesn't have a "working language". I suppose I could check the author's working language and see if it's different, e.g. if a Francophone author were to write a Start Trek novel, but I am not sure it would be useful. Besides, there would be complications when dealing with collaborations by authors whose working languages are different, e.g. Lords of Terror by Allan Cole and Nick Perumov. Ahasuerus 18:01, 23 January 2014 (UTC)

Good. I particularly like the second one. It helps when looking at an author's summary page to see which original works were published in a different language. Thanks. Mhhutchins

Helliconia Spring note to all verifiers

In my german edition there's a letter by Aldiss preceding the novel that gives some background information on the development of the book (or rather the trilogy). So, I'll enclose this as an essay. I just wonder if this should have been the original publication, so I would like to recommend for checking your respective publications. Stonecreek 19:53, 23 January 2014 (UTC)

Patch r2014-59 - Series numbers

Non-integer series numbers like "0.5" and "7.75" are now supported. As the updated mouseover Help says, "Series numbers must be between 1 and 999999999. You can use a decimal point and up to 4 digits after it to position titles in between other titles in the series, e.g. 3.5 will appear between 3 and 4". A few examples are available on Jennifer Estep's Summary page.

Please note that this was a major change and affected over a dozen different areas. If you see any new problems or unexpected behavior, please report it here. Ahasuerus 15:30, 24 January 2014 (UTC)

This script will have to be re-written. It thinks the numbers are duplicate. Mhhutchins 04:35, 25 January 2014 (UTC)
Thanks, I will take a look tomorrow. Ahasuerus 05:43, 25 January 2014 (UTC)
Fixed. Ahasuerus 06:09, 25 January 2014 (UTC)
And I don't particularly like the way an editor is using it to add shortfiction into the numbering of the novel series. There should be a rules discussion concerning this. Mhhutchins 04:35, 25 January 2014 (UTC)
Well, that was the original intent of FR 360, which read "Many recent series include short fiction pieces and even novel[s] that fall "in between" regularly numbered series entries, e.g. 2.5 and 3.5. It would be desirable to allow these non-integer series numbers."
The reason for this FR was that many recent series, especially in the urban fantasy/paranormal romance sub-genres, use this numbering scheme because their reading order is inflexible and includes short fiction. For example, Jennifer Estep's Web site lists books 1-11 and "e-novellas" 5.5 and 8.5 in the "Elemental Assassin" series. Her "Mythos Academy" series includes books 1-6 as well as e-novellas 0.5, 1.5, and 4.5. Similarly, Jennifer L. Armentrout's Web site lists "Elixir" as "book 3.5" (at 83 pages it's actually a novella).
The list goes and on, which is why Goodreads added support for non-integer series numbers a while back -- see, e.g., their listing for the anthology Hexed, which includes:
  • Kate Daniels, #4.5; Otherworld, #9.5; Stormwalker, #3.5; Anna Strong Chronicles, #6.5
Ditto various review sites, which also use the N.N notation, so we are not exactly trailblazers in this area, just followers trying to keep the software in sync with the changes taking place within the genre. (Of course, not all UF/PR novellas have to be read in order or require a separate number.)
Originally I didn't think it was a high priority, but after entering lots and lots of Notes which all looked like "This is entry 3.5 in the series" while working on Fixer's submissions, I became a convert :) Ahasuerus 05:43, 25 January 2014 (UTC)
As long as the numbering comes from an authorized source (i.e. the author him/herself), I can accept it. But I can see editors attempting to enter short fiction works into other series just to give it a number. There's no reason in my opinion to "order" works based on someone's (not the author's) notion of what goes where. I see no problem in listing unnumbered short fiction at the end of a numbered series of novels, or even giving them their own sub-series. But a subjective ordering can be highly suspect. One person's reading order may differ from another's, just as a chronological ordering would without author input. When I see such changes in the submission queue, I will question the editor and ask them to provide a authorized source for such numbering. Mhhutchins 16:54, 25 January 2014 (UTC)
BTW, I've found Goodreads often to be quite unreliable. I would question any data that is based solely on Goodreads, and would want some corroborating source. Mhhutchins 16:57, 25 January 2014 (UTC)
Oh, absolutely! Even in UF, there are complex cases with multiple sub-series and overlapping timelines, which can make ordering difficult. However, there are also many cases where authors go out of their way to warn their fans about the proper reading order, e.g. "This novella follows DEITY, the Third Covenant Novel, and should be read after DEITY in order to avoid spoilers". It's to address the latter that this FR was implemented :) Ahasuerus 17:21, 25 January 2014 (UTC)

Edit Title changes

Effective 5 minutes ago, it's no longer possible to change a regular title record to an INTERVIEW or REVIEW in Edit Title. The fact that the page allowed you to do that was a bug because INTERVIEW/REVIEW records require interviewers/reviewers, so the converted records were incomplete and invalid. If you need to convert a regular title record to an INTERVIEW or REVIEW, please delete the title and enter a new one. Ahasuerus 18:09, 24 January 2014 (UTC)

Patch r2014-61 - Cover art enhancements

Feature Request 172, "Display cover images for COVERART title records", has been implemented. If a COVERART record is associated with one or more pubs with cover art URLs, those images are now displayed on the Title page.

Note that any images associated with variant titles are also displayed, e.g. Paul Lehr's You Will Never Be the Same, but only if the VT is for a COVERART and not an INTERIORART record. Thus, Lehr's Time Probe: The Sciences in Science Fiction shows the covers of the hardcover and paperback editions of Clarke's book, but not the cover of Anthopology 101: Reflections, Inspections and Dissections of SF Anthologies, where the same image appeared as INTERIORART.

Once everyone has had a chance to look at the results, we can discuss whether we want to modify the Title page logic to display the pub covers for non-COVERART titles. I suspect that there may be value to showing the covers of all editions of the same book in the same place and perhaps even the covers of all pubs where the currently displayed story has appeared. Ahasuerus 01:14, 25 January 2014 (UTC)

Very nice, thanks. Your proposition looks great (I particularly enjoy seeing the covers of the books) but it may perhaps slow the diplay. Hauck 11:38, 25 January 2014 (UTC)
That's a good point, especially for users with slow connections. How about we add a new link, "View all covers for this title", to the Title page and create a new page for covers? Ahasuerus 16:40, 25 January 2014 (UTC)
I like this idea a lot. Hauck 16:59, 25 January 2014 (UTC)
I've seen it on the page now for a while but hadn't tried it yet, as I was worried about display speed. It doesn't seem to slow things down, so I turned it on. Then I discovered that it doesn't show the covers next to the pub, so you don't know which cover goes with which pub. I figured out that you can tell which is which by clicking on the cover, but what I really wanted to know was which pubs have missing covers? (I like to scan and add covers). Could you make it so the cover appears to the left of the pub in the listing? It's OK to make it smaller, since if you need to see a better picture, you can click through to the pub listing. Thanks. Jack. Sjmathis 15:36, 28 February 2014 (UTC)
I like how it makes it much easier to tell if coverart between records is the same. It would be even nicer if the pictures were labeled with pub id so that when you do find one that needs to be de-merged, you don't have to open each publication. -- JLaTondre (talk) 14:04, 25 January 2014 (UTC)
Clicking on an image already takes you to its pub :) Ahasuerus 16:38, 25 January 2014 (UTC)
Also, while you're on coverart improvements :-), it would be nice to display the coverart on the editor's merge screen (when merging coverart title records); the same as is done on the moderator's approval screen. Not that it happens often, but that should reduce incorrect merge requests resulting from someone picking the wrong coverart title record. -- JLaTondre (talk) 14:04, 25 January 2014 (UTC)
Very true, I will create an FR. Ahasuerus 16:40, 25 January 2014 (UTC)
Fantastic new feature. I love it. Mhhutchins 17:43, 25 January 2014 (UTC)
About the display of cover images in non-COVERART title records, I like it, but I would recommend that it be a user option. Can you imagine how long it would take some pages like this to load for some users? Mhhutchins 17:51, 25 January 2014 (UTC)
Yes, that's certainly a consideration. I think we could do two things:
  • Create a new page, linked from the Title page, where all title-related images would be displayed
  • Create a User Preference to show images at the bottom of the Title page
That way those of us with faster connections will see all cover images on the Title page while the rest will be able to follow a link to a separate page when they want to see the covers. And, of course, we'll add a note to the top of the "Covers" page to the effect that you can enable automatic display of covers by changing your User Preferences. Ahasuerus 21:44, 25 January 2014 (UTC)
I stumbled on this new feature tonight. Outstanding! Kevin 05:11, 4 February 2014 (UTC)

Patch r2014-62: REVIEW merging changes

The software has been modified to disallow merging REVIEW records if the reviewed titles are different. There are a couple of messed up records in the database which I will need to clean up manually. Ahasuerus 03:28, 25 January 2014 (UTC)

Garan the Eternal question

Garan the Eternal has two title records (here and here), one listed as a collection and the other as a novel. They appear to link to many of the same publications. I see an explanatory note on the collection but surely this structure is incorrect? If it's really a collection (though it sounds more like a fixup) then surely there should still be only one title record. Or am I confused? Mike Christie (talk) 17:54, 25 January 2014 (UTC)

Garan the Eternal, the novel, is a fix-up of two shorter pieces (here and here). But it's only been published in English as part of a collection of the same title with two unrelated stories. (Some of the translations have been stand-alone publications of the novel.) Imagine the collection was given a different title, it would still contain the novel and two short stories regardless. A novel's title record (like a short story's title record) will list all of the publications in which that novel (or story) appeared, including collections, anthologies, and omnibuses. A collection's title record will only list the publications which are the collection itself. It can be confusing, I admit. Some editors have added explanatory notes in the pubs and the titles. Mhhutchins 18:18, 25 January 2014 (UTC)
BTW, without having a copy of the book and doing an actual word count, you might find that the fix-up work may not even qualify as a NOVEL (if it's less than 40K). If that were the case, it would be somewhat simpler to understand. We'd changed it from NOVEL to SHORTFICTION with a story length of "novella". And then it would just be another SHORTFICTION content in the collections. (But then the translated books would have to be converted to CHAPTERBOOK, and that opens another can of worms!) Thanks. Mhhutchins 18:27, 25 January 2014 (UTC)
OK, that explains it. I suspected I was confused -- it's pretty rare I find a mistake in y'all's work! Mike Christie (talk) 18:39, 25 January 2014 (UTC)

Import/Export fixed

The Import/Export logic has been fixed not to import/export title records if the destination pub already contains the same titles. Thus, if you try to Import Contents from a pub with Titles 1, 2, 3 and 4 into a pub which contains titles 3, 4, 5 and 6, only titles 1 and 2 will be imported.

As of this morning, there were a few dozen pubs with duplicate titles and I plan to post a full list on one of the Bibliographic Project pages later tonight. Once they have been cleaned up, we should be rid of duplicates once and for all. (I know, famous last words...) Ahasuerus 02:49, 26 January 2014 (UTC)

Diff Publications fixed

Diff Publications has been changed to rely on IDs rather than the spelling of each title when determining whether two titles records are identical. In addition, the publication numbers at the top of the page have been hyper-linked to their respective pubs. Ahasuerus 05:40, 26 January 2014 (UTC)

Amazon links for ebooks with ISBNs

Amazon links for ebooks with ISBNs have been fixed. Due to Amazon's limitations, they don't take you directly to the Amazon record, but they put you on a search page with one result, at which point you are only one click away. Once we add support for "third party identifiers" like ASINs, we'll be able to link to ISBN-less e-books as well. Ahasuerus 17:25, 26 January 2014 (UTC)

Were you aware that most major publishers actually assign ISBNs to ebooks and that only Amazon doesn't give the number in their listings? B&N does.Mhhutchins 18:06, 26 January 2014 (UTC)
Oh yes. Amazon does have their ebooks' ISBNs (if they exist) on file, as can be seen by the fact that you can search for ebooks by ISBN, but they are not displayed. I am not sure why they do it that way; perhaps they don't want to make it easy for customers to tell ISBN-less ebooks from ISBN-enabled one? Strange. Ahasuerus 21:32, 26 January 2014 (UTC)
Can Fixer cross-reference a title on Amazon with B&N's listing so that the ISBN becomes part of the record? Mhhutchins 18:06, 26 January 2014 (UTC)
I am afraid it's not easy to do, but we will definitely need to address the issue in the foreseeable future. If we can't reconcile ASINs and ISBNs, we may end up with a significant data duplication problem when we try to improve our ebook coverage. Ahasuerus 21:32, 26 January 2014 (UTC)
Or can Fixer find the publication's ISBN from Amazon even if it isn't visible in their listing? Mhhutchins 18:06, 26 January 2014 (UTC)
On rare occasion, Fixer does get e-ISBNs from Amazon, mostly from Amazon UK. I haven't been able to discern a pattern, but it happens so rarely as to be almost inconsequential. For now, Fixer simply adds ebooks' ASINs to one of his internal queues. I expect that we will need to add "third party identifier" support before we can leverage them. Ahasuerus 21:32, 26 January 2014 (UTC)
But would adding a field for the ASIN actually help in identifying a work based on the publisher's ISBN? Mhhutchins 22:41, 26 January 2014 (UTC)
Well, the "third party identifier" field wouldn't be just for ASINs, it would also be used for LCCNs, OCLC numbers and for any other identifiers we may want to add -- Reginald-1/3, Tuck, Goodreads, OpenLibrary and so on.
That said, it is true that adding it won't help in identifying ISBNs. Ahasuerus 02:28, 27 January 2014 (UTC)
I'd much rather efforts go to finding publisher ISBN than adding an extra field for third party identifiers. Mhhutchins 22:41, 26 January 2014 (UTC)
Undoubtedly, it's better to have an ISBN than an ASIN, but getting the former rather than the later can be challenging. However, I have spent the last couple of hours experimenting with Amazon and -- lo and behold! -- I seem to have made some progress. If you check submission 2302752, which is currently sitting in the queue, you will see that Fixer was able to create a submission for an e-book and that it has most of the standard fields populated. There is no price because Amazon only lists the current discounted price ($3.63) and no list price, but B&N has it for sale for $3.99, which looks about right for a novella+associational material. On the other hand, B&N lists the publisher as "Penguin Group (USA)" while Amazon specifies that the publisher is "InterMix", but that the book is "Sold by: Penguin Group (USA) LLC". Similar issues exist with submission 2302780, which was based on Amazon UK's data. So it's a mixed bag, but much better than nothing. Thanks for prompting me to dig deeper! Ahasuerus 02:28, 27 January 2014 (UTC)
Well, you're welcome. Hope I didn't push too hard. :) Concerning the submission 2302752: as is typical of Amazon, I didn't get any response from the "Additional Sources" link in the submission, but (a BIG BUT) there was a good link back to B&N. And that's good enough for me. Now about those publisher credits, I can't see there ever being a way to tie down exactly who publishes something so ephemeral and non-concrete as an ebook. (My friend James Goddard calls them "smoke and mirror" editons.) Thanks. Mhhutchins 02:48, 27 January 2014 (UTC)
Oops, I completely forgot about those links when I fixed the links in the navigation bar earlier today! Sorry about that, I'll fix them shortly. Ahasuerus 03:19, 27 January 2014 (UTC)
I didn't mean to say there was a problem with those links (were there?), but that ebooks with ISBNs never link to Amazon, either on the publication record or the submission source links. I think Amazon just wants to get rid of ISBNs as far as ebooks go, and wanting their identifier for the Kindle edition (the ASIN) be the only one used. Mhhutchins 03:47, 27 January 2014 (UTC)
Although Amazon doesn't display ISBNs for ebooks, you can still use them to link to ebooks. You just need to use special "search" URLs, which were implemented (for Amazon/ebooks only) earlier today. The result is not a direct link, but it puts you on an Amazon Web page with one search result, which is as close as we can get. If you refresh the page for submission 2302752 and follow one of the Amazon links (.com, UK and .ca all have this ebook), you'll see what I mean :) Ahasuerus 04:24, 27 January 2014 (UTC)
So they just implemented that kind of search today or was it something you did in the ISFDB software to force a search on Amazon? Either way, I'm glad. It's a handy tool. Thanks. Mhhutchins 04:31, 27 January 2014 (UTC)
It's been available for a while, not sure exactly how long. Last January Uzume described the URL structure in his comment on SourceForge and I saw it the other day when I was reviewing the list of outstanding bugs. Once I confirmed that Uzume's approach worked, implementing it took less than an hour. And BTW, we are down to 32 open Bugs, the lowest number since beta :) Ahasuerus 04:39, 27 January 2014 (UTC)
By adding the ASIN as part of the ISFDB record, we're actually succumbing to Amazon's attempt to dominate the publishing industry. (Believe me, that's not hyperbole!) Mhhutchins 22:41, 26 January 2014 (UTC)
Well, we could also use the envisioned "third party identifier" field to record "BN IDs" (Barnes and Noble IDs), which B&N uses for books without an ISBN, or any other IDs that may become important in the future. Ahasuerus 02:28, 27 January 2014 (UTC)
So is the proposed third party identifier field going to be an "Add Another ID" type field? That's the only way I can imagine it could include multiple identifiers. If so, we wouldn't be bowing to the Gods of Amazon. Mhhutchins 02:48, 27 January 2014 (UTC)
Oh, definitely. If anything, it will need to be more sophisticated than a run of the mill "Add Author/Web page/Email" button: for every third party ID you will need to provide ID type (LCCN, ASIN, OCLC, etc from a drop-down list) as well as the ID itself. It will be similar to the way "Add Title/Review/Interview" works in the Content section of New/Edit/Clone Pub -- when you click on a button, it displays a small new section with a few fields in it.
Sorry, I assumed that all of the above went without saying, but apparently my telepathic abilities are not as as good as I thought :) Ahasuerus 03:19, 27 January 2014 (UTC)
That sounds very complicated, but I have confidence you'll be able to do it. Mhhutchins
It's not inherently complicated, but it's rather tedious and error-prone. Our software doesn't take advantage of many third-party tools which automate the process of building interactive Web pages, so almost everything has to be done manually. Ahasuerus 04:24, 27 January 2014 (UTC)

Alphabetical Bibliography page - partial fix

The Alphabetical Bibliography page has been fixed to display VTs. Translations are also shown based on the currently signed-on user's Language Preferences. There is a known bug with some VTs, which do not always display a list of co-authors. Ahasuerus 20:17, 26 January 2014 (UTC)

Server problems

The server has been very sluggish for the last few hours. I have tried a few things and it looks healthier right now, but I guess we'll see how long it will stay happy. Ahasuerus 20:27, 29 January 2014 (UTC)

Major problems today, sorry... Ahasuerus 21:25, 30 January 2014 (UTC)
Yes, I noticed it as well, but wrote it off as a result of the freezing weather here in the Deep South. It's enough to slow down anybody (and anything!) :) Mhhutchins 21:34, 30 January 2014 (UTC)
The server is somewhere in the Chicago area, where it's a balmy 32 degrees today :) Ahasuerus 22:55, 30 January 2014 (UTC)
Compared to Georgia, that IS balmy. Mhhutchins 23:29, 30 January 2014 (UTC)
Can't remember the last time it was 32 degrees here. The high for the next week is 25º. Gotta love Wisconsin. I have no idea how the 49'ers managed to come here from California, play in an outdoor stadium, and still beat the Packers :-) Chavey 15:15, 31 January 2014 (UTC)

Help with reprint of collection

I'm afraid I'm very out of practice and need a bit of help here. I have this pub in front of me; it's a reprint of this one. The contents are identical with the same titles and page numbers. What's the best way to copy the contents into this publication? I would guess it would be to delete the pub and recreate it as a clone of the first printing, but I thought I should check. Mike Christie (talk) 03:35, 31 January 2014 (UTC)

Go to the contentless record and click on the link "Import Content" under the Editing Tools menu. In the top box on the next screen enter the record number of the publication with contents, which is 302148, in this case. If the page numbers of the contents are the same, leave the box checked, and click the button "Import Content". On the next screen, you have the option to add new contents, but you can't change any of the meta data. (That must be done in a separate submission.) At the bottom of the page, click the button "Submit Data". Once the submission is moderated, look over the record and if everything is OK, do a primary verification of the record. Mhhutchins 05:19, 31 January 2014 (UTC)
Done; thank you. Mike Christie (talk) 00:10, 1 February 2014 (UTC)

Patch r2014-75 - Language enhancements

Based on user feedback, the 4 Bibliography pages have been changed to show the currently logged in user's language preferences. Ahasuerus 01:16, 4 February 2014 (UTC)

Cover art link on the Publication Listing page

The other day I noticed that when the Publication Listing page displays the cover artist's name, the hyperlink takes you to the artist's Summary page. Wouldn't it be more useful to link to the COVERART page instead? Alternatively, the artist's name(s) could be left the way it is, but the word "Cover" could be hyperlinked to the COVERART record. Ahasuerus 03:01, 4 February 2014 (UTC)

If we have a choice, I'd have to go for the latter. Linking an author/artist's name to anything other than their summary page is so out-of-sync with the function throughout the remainder of the database, it would really mess up some minds. Mine being one of them, since it's become second nature that an author/artist's name is linked to his/her summary page. Mhhutchins 03:24, 4 February 2014 (UTC)
Oh! Yes, that makes a great deal of sense. Thanks! Ahasuerus 03:51, 4 February 2014 (UTC)
Done. Also added a link to the Title page, which takes you to a new page which displays that title's covers. A User Preference to display covers on the Title page will be added later. Ahasuerus 04:12, 4 February 2014 (UTC)
This "Title covers" is really nice! And if someone is looking up what edition of a book they have, it could be very useful, as well as just cool. Chavey 23:43, 11 February 2014 (UTC)

New User Preference

A new User Preference, "Display cover images on the Title page by default", has been added. Ahasuerus 19:18, 4 February 2014 (UTC)

Nice! Thank you. --Willem H. 20:38, 4 February 2014 (UTC)
I agree. Making it set by the user was the best way to handle it. Thanks. Mhhutchins 21:11, 4 February 2014 (UTC)

Publication Series and covers

The Publication Series page has been enhanced to allow viewing all covers for the displayed series, e.g. Ace SF Special, Series 2. Ahasuerus 22:26, 4 February 2014 (UTC)

P.S. Now that the Publication Series page supports Notes, third party URLs and cover display, I think we can move the remaining 22 Wiki pages in the Publication Series category to the ISFDB proper. As an added bonus, we'll be able to fill in certain gaps in our publication series coverage, e.g. compare Series:Winston_Science_Fiction and Winston Science Fiction. Ahasuerus 22:37, 4 February 2014 (UTC)
Fantastic! Mhhutchins 23:08, 4 February 2014 (UTC)
And to make it complete, I have added the ability to view covers on the "Books Published in YYYY" page, e.g. Ace Books - Books Published in 1955. Ahasuerus 23:57, 4 February 2014 (UTC)
You are just great!!! Stonecreek 09:27, 5 February 2014 (UTC)
Excellent enhancement! This will make all sorts of work on covers that much quicker and easier. PeteYoung 09:36, 5 February 2014 (UTC)
Thanks for the kind words! :) Ahasuerus 16:30, 5 February 2014 (UTC)

Ordering pub contents

(Based on a recent Help Desk discussion.)

The way the Contents ordering algorithm currently works is as follows:

  • Ignore square brackets for ordering purposes (this was FR 210)
  • Display all titles without page numbers first
  • Display 'fc' (=front cover) next
  • Display 'fep' (=front end paper) next
  • Display Roman numerals next
  • Display Arabic numerals next
  • Display 'bep' (=back end paper) next
  • Display 'bc' (=back cover) last

This works OK in 90%+ of all cases, but there are a number of scenarios where the logic fails as described in FR54:

  • multiple titles, e.g. two short poems or a story and its artwork, on the same page
  • books where numbering is restarted for various reasons, e.g. Ace Doubles, omnibuses, etc
  • unnumbered pages prior to page 1
  • uncommon page numbers like A-1, B-2, etc

Here is a proposed solution:

Allow (optionally) appending "sorting" page numbers to the currently defined "displayed" page numbers. To use Regarding Sherlock Holmes: The Adventures of Solar Pons as an example, the two essays which appear prior to page "1" and which are currently labeled "[7]" and "[11]" would be entered as "[7]|0.1" and "[11]|0.2". They would then appear before "The Adventure of the Frightened Baronet" on page "1" and their displayed page numbers would still be "[7]" and "[11]". In the case of The Metal Man and Others, the illustrations would be numbered something like "plate 1|0.01" through "plate 19|0.1" while the titles currently entered as "iv" and "xv" would be changed to "iv|0.51" and "xv|0.52". And in cases where there are multiple titles per page, they could be entered as "50|50.1", "50|50.2", etc. Of course, if there is no "vertical bar" (or "pipe") character present, then everything will be handled the way it currently is.

Would this work for everybody? Ahasuerus 16:50, 5 February 2014 (UTC)

I like it. This would solve display problems for those relatively few records (a couple thousand, maybe?) Thanks. Mhhutchins 17:13, 5 February 2014 (UTC)
I am for it, too. Stonecreek 18:33, 5 February 2014 (UTC)
I would like to have 'bp' (=unpaginated pages that precede pagination) between 'fep' and Roman numerals. Otherwise all in favor. --Willem H. 07:19, 6 February 2014 (UTC)

Extra long notes and synopses

As you know, we have been working on adding Notes fields to various records (most recently Series) so that we could eventually move all of our Bio, Author, Series, Awards, etc pages from the Wiki to the database. However, a quick review of sample Bio/Author/Series pages shows that they can be quite long. If we were to display them at the top of their respective Author/Series pages, they would crowd out the bibliographic content, which seems undesirable. Similarly, there are synopses and Title notes which can get in the way of bibliographic data, e.g. cf. The People of the Moon.

I propose that we modify the software to limit the display of each Synopsis, Note and -- once implemented -- Bio and Author fields to the first N characters just like we limit the display of tags on Bibliography pages to the first 20 (see Kim Stanley Robinson's page.) And just like we do with tags, if there is more data in the field than can be readily displayed on the main page, the software will display a link to a separate Web page where users could view the whole thing in all its unabridged glory.

Does this sound like a reasonable solution to the problem? Ahasuerus 17:23, 5 February 2014 (UTC)

It does for me! Stonecreek 18:32, 5 February 2014 (UTC)
And me as well. Mhhutchins 20:17, 5 February 2014 (UTC)
You know, it occurs to me that this could also help address the issue of spoilers in synopses. Currently Help says that the Synopsis field is for a "non-spoiler synopsis". However, there are many cases where you can't really describe more than a small part of the plot without some type of spoilers. If we had a separate page for Synopses as per the proposal above, we could change Help to say something like "Enter a short non-spoiler synopsis. If spoilers are unavoidable, enter the non-spoiler part of the synopsis first, then "SPOILERS:" and then the rest of the synopsis". The Title page would then display the synopsis up to "SPOILERS:" (unless it was too long and then it would be truncated as per above) and then a link to the Synopsis page with the words "View full synopsis - contains SPOILERS!". How does it sound? Ahasuerus 21:30, 5 February 2014 (UTC)
I think this is an excellent idea, including the part about suppressing spoilers. For the user interface to the full synopsis, may I suggest the "Read more ›" link, such as folks are used to from amazon, imdb, etc.? Chavey 12:27, 7 February 2014 (UTC)
Well, I am all for consistency, but there appear to exist a few different conventions out there. For example, IMDB mini-bios say "See full bio »" while Amazon uses "show more". Ahasuerus 04:31, 8 February 2014 (UTC)
As we say in the computer biz, the nice things about standards is that there are so many to choose from. Chavey 15:13, 8 February 2014 (UTC)

New User Preferences

Two new User Preferences have been added: "Suppress translation warnings on Bibliography pages" and "Suppress bibliographic warnings on Title pages".

BTW, we also have an old FR to "Add a User Preference to suppress Reviews in Title Display", which I documented based on someone's comment back in 2010. Is this still desirable? Ahasuerus 02:58, 7 February 2014 (UTC)

Thanks. Even though I understand their necessity for new users, those translation warnings were really starting to bug me. Mhhutchins 00:01, 11 February 2014 (UTC)
Me too :-) So how about the FR to "suppress Reviews in Title Display"? Should I close it? Ahasuerus 02:57, 11 February 2014 (UTC)
I find the display of reviews in title records to be very useful, but I suppose some users might find them annoying. If it's not too hard to implement, I have no problem with giving users a choice. Mhhutchins 03:43, 11 February 2014 (UTC)

Patch r2014-83 - Enhanced display of disambiguated authors

Summary (and other) Bibliographies of disambiguated authors have been changed to display a note at the top of the page, e.g. see Andrew Smith (artist). Ahasuerus 00:53, 9 February 2014 (UTC)

Nice feature; thanks! Mike Christie (talk) 01:30, 9 February 2014 (UTC)

Proposed changes to New Pub - CHAPTERBOOK

Would it be desirable to add a check to "New Pub - CHAPTERBOOK" so that it wouldn't let editors submit the form unless the Contents section contained at least one SHORTFICTION or POEM title? Ahasuerus 14:42, 11 February 2014 (UTC)

Yes it would, at least for me. (Very likely it would be very difficult to add a check for too much shortfiction, I think, or would it?) Stonecreek 15:55, 11 February 2014 (UTC)
Could you please clarify what you mean by "too much shortfiction"? Do you mean that we should limit the number of Contents entries to, say, 500 because the approval process tends to hang if a pub has more than 500 titles? Ahasuerus 16:11, 11 February 2014 (UTC)
If I understand the original question, then there would be a warning if the editor submits a CHAPTERBOOK-typed record which doesn't contain a single SHORTFICTION or POEM content record. If that's the case, a hardy "yes". That warning should also apply if the submission includes more than one of either of those content record types. (I think that's what Christian was referring to.) Mhhutchins 16:48, 11 February 2014 (UTC)
The Help page for NewPub says, of ChapterBooks, "if such a publication contains multiple works of fiction, it is usually better to list them as anthologies or collections". It does not forbid a Chapterbook from containing, say, multiple poems. So this proposal would be a rule change. Chavey 00:00, 12 February 2014 (UTC)
That should be clarified ("it is usually better to list them" should be changed to "it should be listed".) It has never been acceptable for a CHAPTERBOOK record to contain more than one content record of either SHORTFICTION or POEM type. And the whole section about "This publication type may also used for anything smaller or flimsier than a standard paperback." should be removed entirely. It confuses the general definition of "chapbook" with the ISFDB definition of CHAPTERBOOK. Mhhutchins 00:21, 12 February 2014 (UTC)
I started a discussion on the Rules & Standards page in order to update the documentation to reflect the working definition of CHAPTERBOOK. Mhhutchins 01:07, 12 February 2014 (UTC)

Submissions via the Web API

I have recently tested submitting issues of Nature via the web API, and I'd like to submit further issues in the same way - it's much faster (and at the same time hopefully less error-prone) than using the browser-based form. I would post batches of about 20 submissions, as suggested here; is there anything else to consider when using the web API? Fsfo 22:25, 13 February 2014 (UTC)

The Data Submission Formats page doesn't reflect some of the changes that have been implemented over the last years, but as long as you stick to New Publication submissions, you should be fine. I plan to update the other pages shortly. Ahasuerus 22:52, 13 February 2014 (UTC)
Done. Ahasuerus 20:21, 14 February 2014 (UTC)

Patch r2014-87 - Tabbing changes

Numerous changes have been made to New Pub, Edit Pub, Clone Pub and Import/Export Content to facilitate tabbing between fields. (New Pub still needs polishing.) Edit Pub has been enhanced to display inline help.

As always, if you see anything abnormal, please report it here. Ahasuerus 22:37, 14 February 2014 (UTC)

New report added

A new report, "Percent of Books by Type by Year", has been added to the ISFDB Statistics and Top Lists menu. Ahasuerus 03:24, 15 February 2014 (UTC)

Ditto Percent of Publications by Format by Year. Ahasuerus 05:10, 15 February 2014 (UTC)
This last chart is very interesting, a visual history of the decline and fall of various formats. Nice work. Mhhutchins 05:49, 15 February 2014 (UTC)

Larry Niven's Rainbow Mars

We had two records, both of type COLLECTION, for Larry Niven's Rainbow Mars. As far as I can tell, this should be one NOVEL record and one COLLECTION record with the collection containing the novel. There are also several pubs which appear to be just the novel based on page count.

I believe I have sorted it out, but would like the verifiers to double check.

Novel: 1696531
  • 372638 (translation) - primary verified by Willem H. => Novel only. --Willem H. 19:50, 16 February 2014 (UTC)
  • 216805 - no primary verifier, Locus1 verified by ErnestoVeg (Novel only with the new afterword according to Locus1, so this and the following are correctly entered. I'll add the afterword to each.)
  • 216809 - no primary verifier, Locus1 verified by ErnestoVeg (see note above)
Collection: 19664
  • 27302 - primary verified by BLongley, Dragoondelight, Willem H., Hauck, & Syzygy => collection indeed. Hauck 09:25, 16 February 2014 (UTC)
  • 273288 - primary verified by Ahasuerus & Bluesman
  • 154651 - no primary verifier, Locus1 verified by ErnestoVeg

As ErnestoVeg is no longer available, if another Locus owner could double check his Locus1 verifications, that would be appreciated.

Also, all of the reviews are for the collection. If the review verifiers could double check that these are for the novel or the collection, that would also be appreciated.

  • 205829 (contains two reviews, p26 & 29) - verified by Mhhutchins
  • 56941 - verified by Tpi, Swfritter, Hauck, & Teddybear => OK. Hauck 09:25, 16 February 2014 (UTC) Collection--swfritter 20:50, 16 February 2014 (UTC)
  • 328127 - verified by BLongley & Hauck => was for the novel (note that the endnote implies that the Afterword is not present in the Orbit HC). Hauck 09:24, 16 February 2014 (UTC)

I will leave notes with all the verifiers. Since several of these have multiple verifiers, once one of the verifiers has checked it, I recommend striking out (use <s></s> tags) or making a note of some kind. Thanks for your help. -- JLaTondre (talk) 21:52, 15 February 2014 (UTC)

The Locus reviews are of the collection. Mhhutchins 22:08, 15 February 2014 (UTC)
273288 checked. Ahasuerus 22:12, 15 February 2014 (UTC)

Web server tweaks

The Web server settings have been tweaked ever so slightly. Hopefully it will work better than the last round in mid-2013 when a different set of tweaks caused numerous hangs and had to be backed out. Ahasuerus 00:27, 16 February 2014 (UTC)

Well, the server was so slow this afternoon, that I just gave up. It seems to be working better now. Mhhutchins 01:21, 16 February 2014 (UTC)

Bill Longley update

Earlier today I received an e-mail from Bill Longley's father. I am afraid the news is not good. After a long illness and multiple hospital stays, Bill passed away on February 5. IIRC, he was only 48 :( Ahasuerus 19:12, 16 February 2014 (UTC)

M.... as we say in France. Hauck 19:33, 16 February 2014 (UTC)
I received a message too, mid-afternoon. A few days ago I e-mailed Bill because of his prolonged absence, enquiring as to his recent health. Needless to say the reply came as a shock, given that in October his diagnosis was 12-18 months. He only got 4. In his last e-mail to me he said "I've no real complaints about dying comparatively young, I just want it to be painless." I hope he got his wish. His father, Bill Sr., is now "trying to tie up loose ends". :( PeteYoung 19:56, 16 February 2014 (UTC)
Shocking. I do hope it was painless. --Willem H. 20:04, 16 February 2014 (UTC)
Terrible news. It's nothing you want to hear about someone so young. He'll be sorely missed, as his contributions to this database, although countable, were truly immeasurable. Mhhutchins 20:29, 16 February 2014 (UTC)
Speechless and gloomy Rudam 20:48, 16 February 2014 (UTC)
I'll be tipping a pint in his direction .... Cheers! --~ Bill, Bluesman 22:38, 16 February 2014 (UTC)
Changed that to a snifter of fine cognac ... his Lordship deserves the best! --~ Bill, Bluesman 02:39, 17 February 2014 (UTC)
Sad news; I worked a lot with Bill years ago, when I was active here. I'll be drinking to his memory as well. Mike Christie (talk) 00:06, 17 February 2014 (UTC)
Very sad news. --Chris J 03:02, 17 February 2014 (UTC)
I didn't come to know him personally (but we might have met on one of the few Worldcons I was attending), but I'll remember him as the kind and friendly person he oobviously was when I come over one of the many pub.s he added and/or verified. Stonecreek 09:21, 17 February 2014 (UTC)

(unindent) I've heard from Bill's father again. After going several rounds with various specialist UK dealers, Bill Sr. has managed to pass on Bill's entire SF and comics collection to a local dealer, David's Books in Letchworth Garden City, Hertfordshire. They offered £500, which Bill Sr. thought "was a good offer, in any case a great relief to get shot of the lot in one go. I'm jolly glad we haven't got to invite all the local charity shops to come and pick up a dozen boxes each." PeteYoung 03:04, 28 February 2014 (UTC)


A word of warning about Goodreads. Their "Born in" field occasionally contains the state/province/country where the author grew up in rather than the state/province/country where s/he was born. Ahasuerus 21:20, 16 February 2014 (UTC)

Also unknown Month/Day of birth sometimes entered as January 01.--Rkihara 21:54, 16 February 2014 (UTC)
I've never found one bit of data on Goodreads that wasn't found on a more reliable website. I only use it for the reviews to determine if a book is spec-fic. Mhhutchins 22:11, 16 February 2014 (UTC)
I'll go with Mike on this one. Good for reviews; unreliable for anything else. Chavey 14:04, 17 February 2014 (UTC)
On the plus side, they have a lot of ISBNs, including translations, which we do not have (yet! :-) Ahasuerus 05:19, 18 February 2014 (UTC)
But like Amazon, they don't distinguish between the stated ISBN and the derived one. I've had to change many publication records in which the editor used Goodreads as the source for the ISBN and got it wrong. Mhhutchins 05:48, 18 February 2014 (UTC)

Brief ISFDB outage

In a few minutes I will need to disable editing for 60-120 seconds. No need to panic :-) Ahasuerus 04:31, 18 February 2014 (UTC)

Done. I will be posting the patch notes shortly. Ahasuerus 04:34, 18 February 2014 (UTC)

Patch r2014-93 - Page numbers

Page number processing has been enhanced as follows:

  • Page numbers with double quotes no longer mysteriously disappear in Edit Pub and Clone Pub.
  • Page numbers with apostrophes no longer cause errors at approval time.
  • You can delete page numbers associated with reviews and interviews.
  • The database definition has been changed to allow up to 20 characters in the page number field. If you try to enter more than 20, you will get a pop-up message informing you about this limitation.
  • If you enter a page number but no other information about a Content title, you will get a pop-up message.

Now that these issues have been addressed, I can start working on adding the "|" capability discussed a few days ago. Ahasuerus 04:52, 18 February 2014 (UTC)

Patch r2014-94 - Ordering Content items on the Publication Listing page

As per our discussion 2 weeks ago, I have added the ability to append "sorting" numbers to regular page numbers. To enter a "sorting" page number, append the "pipe" character ("|") to the end of the regular page number value and then enter the number that the software will use to determine where to display the current Content item.

For example, in the case of Regarding Sherlock Holmes: The Adventures of Solar Pons, the introductory essays "In Re: Solar Pons" and "A Word from Dr. Lyndon Parker" have had their page numbers changed to "[7]|0.1" and "[11]|0.2" respectively so that they would appear before "The Adventure of the Frightened Baronet" on page 1. The page numbers of the plates inserted between pages 298 and 299 in The Metal Man and Others have been changed to "plate 1|298.1", "plate 2|298.2", etc to make them appear in the right place.

Also, you can enter "sorting" page numbers even if there are no regular page numbers defined, e.g. in a box set -- see The Hunger Games Trilogy Boxset.

As previously discussed, this functionality can be useful when dealing with:

  • multiple titles, e.g. two short poems or a story and its artwork, appearing on the same page
  • books where numbering is restarted for various reasons, e.g. Ace Doubles, omnibuses, etc
  • unnumbered pages prior to page 1
  • uncommon page numbers like A-1, B-2, etc
  • boxed sets where volumes appear out of order

The relevant Help pages will be updated shortly. Ahasuerus 01:24, 20 February 2014 (UTC)

Nice. Mhhutchins 01:35, 20 February 2014 (UTC)
Template:PubContentFields:Page has been updated. Please feel free to edit it if anything looks wrong -- I have been under the weather for a while. Ahasuerus 01:43, 20 February 2014 (UTC)
As an added bonus, "bp" and "ep" are now supported by the page sorting algorithm. But the real bonus (IMHO) is that we can now discuss data entry conventions without having to worry about their impact on the order in which Content items appear. Ahasuerus 02:31, 20 February 2014 (UTC)

Web server crash

FYI, the Web server crashed this morning and was down until 11:20am server time. Our log files show that we were apparently under attack from a malicious bot looking for security vulnerabilities shortly before the crash, but it's not clear whether the two events are related. Ahasuerus 17:50, 20 February 2014 (UTC)

Patch r2014-96 - Tag changes

The way tags are displayed has been changed. If an author has a tag associated with him/her, clicking on the tag's link on the Summary page takes you to a new page which lists that author's titles marked with the specified tag. For example, clicking on "science fiction" on Larry Niven's page take you to a list of the 13 Niven titles which are currently marked with the "science fiction" tag. From there, you can click on "View all users and titles for this tag" at the top of the page, which will take you to the familiar "Titles marked with tag science fiction" page. In addition, the tag page has been optimized and should load somewhat faster. Ahasuerus 05:24, 21 February 2014 (UTC)

Patch r2014-98 - Duplicate Finder enhancements

Duplicate Finder has been enhanced as follows:

  • The page loads much faster now. This should be especially noticeable when working with authors who have thousands of title records associated with them (Robert E. Howard, Robert Silverberg, etc.)
  • The list of potential duplicates is now sorted alphabetically
  • "Similar Mode" has been disabled for authors with more than 1,000 titles for performance reasons
  • The name of the reviewed author appears in the page header

Additional improvements are in the pipeline. Ahasuerus 01:38, 22 February 2014 (UTC)

The following additional enhancements have been implemented:
  • Exact Title Mode has been changed not to report SHORTFICTION/NOVEL, SHORTFICTION/NONGENRE, COLLECTION/CHAPTERBOOK, NOVEL/COLLECTION and NOVEL/POEM pairs as potential duplicates
  • The logic underlying Similar Title Mode has been overhauled. It now finds titles that are identical except for:
  • punctuation
  • articles (the, a, an)
  • common prepositions
  • a few conjunctions (as, than -- we may want to expand the list)
  • The old logic behind Similar Title Mode is still available for authors with fewer than 1,000 titles, except that now it's known as "Aggressive Title Mode"
Ahasuerus 03:59, 22 February 2014 (UTC)

Patches r2014-100 and r2014-101 - Authors By Debut Date

Authors By Debut Date, a report created by Bill Longley in 2011, has been enhanced and moved from the Wiki to the ISFDB Statistics and Top Lists page. Ahasuerus 05:19, 23 February 2014 (UTC)

Patch r2014-102 - Award Type enhancements

Two new fields, "Award By" and "Award For", have been added to the Award Type record. Once I finish reconciling the Wiki-based Award page with the database, I will add these fields to the Search results page for awards and also create an Award Directory page. Ahasuerus 20:25, 23 February 2014 (UTC)

Thanks for the work on this, and for maintaining the data I had entered into the older Wiki page as you did this (while adding the data for those two fields). One note: In the original wiki page description, I wrote "The categories of awards offered occasionally develop over the years, and where this is the case, we list the current categories." You maintained that sentence, but I believe it's no longer true. Unless I misunderstand, the listing of categories shown on the awards page is NOT limited to the categories currently being used, but includes every category used during the award's history. I didn't change this, because I'm not absolutely certain of how you're handling the categories shown, but assuming my previous sentence is correct, you should delete that sentence. You might wish to consider two listings: Current categories, and Historical categories. Of course I'd also like to resolve the issue of, e.g. two categories called "Novel" and "Best Novel" for the same award. Chavey 16:38, 25 February 2014 (UTC)
All true, but the software modifications that I am working on today will necessitate even more changes to the text, so my devious plan is to rewrite that whole section once I deploy the latest iteration :) Ahasuerus 21:33, 25 February 2014 (UTC)
P.S. As far as categories go, they need to be overhauled so that each one would have a separate record, complete with a list of third party Web pages and Notes. They also need to have separate pages so that you could pull up, e.g., a list of all winners in the "Best novel" category or, alternatively, a list of all nominees and winners in the "Best Fan Writer" category. I expect to get much of it done in the next few days. Ahasuerus 21:40, 25 February 2014 (UTC)

Import content moderator note

I did an Import Content and I wanted to leave a note for the moderator with a question about what I had done, but there is no place to do that. Should there be one? Sjmathis 13:24, 24 February 2014 (UTC)

Good point, FR 554 created. Thanks! Ahasuerus 16:40, 24 February 2014 (UTC)

Patches r2014-103 through r2014-112

A number of changes have been made to the software over the last 24 hours. Here are the highlights:

  • A "Short Name" field has been added to award records. It should be particularly useful when the official name differs from the commonly accepted name, e.g. "Edward E. Smith Memorial Award for Imaginative Fiction" vs. "Skylark".
  • Award searches have been enhanced to check both fields. In addition, the results page shows the "Award For" and the "Award By" fields for each record.
  • An Award Directory page has been created. It lists all of the awards recognized by ISFDB and also links to the Wiki Awards page.
  • Moderators can now enter an untitled award (i.e. an award not linked to a title record) from award-specific overview pages.
  • The "Submit" button at the bottom of the Edit Publication page has been changed to "Submit Changed Data" to distinguish it from the Clone Publication page.
  • Links to Locus, the Science Fiction Awards Database, and are now displayed correctly.

Ahasuerus 06:07, 26 February 2014 (UTC)

Navigation Bar improvements

The "Other Pages" part of the navigation bar has been streamlined and should always display the same links regardless of which page you are on. In addition, the links to the remaining static pages like Author Communities have been moved to the ISFDB Statistics and Top Lists page and the ISFDB Lists page has been deprecated. Ahasuerus 19:47, 26 February 2014 (UTC)

Patch r2014-116: Author Directory improvements

The author directory has been improved to show more uncommon (and often erroneously entered) letter combinations. In addition, the top of the page shows links to the previous and next pages when available. Ahasuerus 01:24, 27 February 2014 (UTC)

Patch r2014-117: Magazine Directory and Publisher Directory implemented

Two new directories have been implemented for magazines and publishers.

Looking at it again, I see that we don't have that many magazine titles, so I wonder if it may make sense to collapse the main magazine directory grid into a single line, with one sub-page per letter. Ahasuerus 05:01, 28 February 2014 (UTC)

I vote for the square grid it's easier to use.__Rkihara 22:35, 28 February 2014 (UTC)
It would appear to me that this grid includes both magazines and fanzines, but the title at the top says "Directory of magazine names beginning with:". May I suggest that this be changed to "Directory of magazine and fanzine names beginning with:" Also, I vote for the square grid. Chavey 01:09, 9 March 2014 (UTC)
Good point, FR 568 has been created. Ahasuerus 01:25, 9 March 2014 (UTC)
Re the magazine grid: since there's relatively few magazine titles, I would prefer a simple single-letter A to Z grid instead of the two-letter system. I can't imagine anyone not being able to find a title even if all of them are listed under a single-letter list. Mhhutchins 01:40, 9 March 2014 (UTC)
Hm, I suppose I can see how a single line across the page may not be as esthetically pleasing as a grid. Perhaps an "A-Z" bullet (i.e. top to bottom) list? Ahasuerus 01:51, 9 March 2014 (UTC)
Aesthetics aside, it would still work. I don't find anything aesthetically appealing about this either, but then we all see things differently. So why not focus solely on the utilitarian appeal? If you're convinced that a grid would work better, how about a 7 x 4 grid with larger fonts? Mhhutchins 03:27, 9 March 2014 (UTC)
I just noticed a typo, that comes by copying the "Author names" code. When I go to the magazine grid, and click on (say) "St", I go to a page that tells me that "Number of magazine last names starting with "st": 41". Odd wording, but of course it's the "last names" that's weirdest. The same thing happens in the publisher list with "publisher last names". Chavey 06:30, 9 March 2014 (UTC)
What happened was that I made the "directory" code more generic and capable of handling other types of records, but overlooked the fact that publishers and magazines do not have last names :-) Fixed now, thanks! (And yes, the wording is a bit odd, but it seems reasonably clear.) Ahasuerus 23:52, 9 March 2014 (UTC)

Patch r2014-118: Cover art enhancements round 3

As per this request, I have changed the Title page to display the word "cover" when a pub has a cover scan associated with it, e.g. see "The Piper's Son". (Adding a miniaturized pic wouldn't be feasible since the software would still need to retrieve the full image before shrinking and displaying it.) Does it look OK? Ahasuerus 18:58, 28 February 2014 (UTC)

Extremely bright!! Is it possible to have this feature an option? I've already set up on my Preferences to have the covers displayed on the bibliographic page for any title and having the new feature as well seems a little overkill. Perhaps with the one Preference chosen the other feature is disabled?? --~ Bill, Bluesman 19:05, 28 February 2014 (UTC)
And the pages seem to take a bit longer to load with the new feature. The cover images at the bottom roll in rather then just appear. --~ Bill, Bluesman 19:12, 28 February 2014 (UTC)
Well, the reason for Sjmathis's request was that he wanted a way to identify pubs without images. If a title is associated with 15 pubs and 12 of them have images, the fact that you can see all 12 at the bottom of the page doesn't make it much easier to identify the 3 image-less pubs.
I do that now with just the images. --~ Bill, Bluesman 00:51, 1 March 2014 (UTC)
As far as brightness goes, we can tone it down -- let me see what I can do.
Performance-wise, there should be no impact on how images are displayed, although you can never be 100% sure with different browsers. Ahasuerus 19:30, 28 February 2014 (UTC)
OK, I have changed the color scheme. Does it look better? (Keep in mind that I am color-blind, so I can only speculate what it must look like to all you color-enabled folks :-) Ahasuerus 19:45, 28 February 2014 (UTC)
That bright blue is too saturated, like a poke in the eye. How about #7C9BCF (sort of lilac), #BBDB88 (light yellow-green), or #FACD8A (light orange).--Rkihara 22:47, 28 February 2014 (UTC)
When you say "bright blue", do you mean the background color or the foreground color of the word "cover"? They both look washed out to me, but then what do I know? :)
BTW, there is a table of "named" CSS colors, which are officially defined by the HTML and CSS specifications. Do any of them look like promising candidates? Ahasuerus 23:06, 28 February 2014 (UTC)
Rather than choosing a drabber color I'd just prefer to be able to turn the feature off. --~ Bill, Bluesman 00:51, 1 March 2014 (UTC)
I'm with Bill here. If I wanted to see if a pub record has a cover, I'd just click on the pub record. All of those "cover" links are somewhat distracting, and make my eyes jump all over the place. Sorry. Mhhutchins 00:59, 1 March 2014 (UTC)
Sounds good, I will turn it into a User Preference. Ahasuerus 01:02, 1 March 2014 (UTC)
I would suggest having this User Preference default to showing the covers. I suspect beginning users are often using this to look up the edition that they own, and in many cases that's easier done via the cover images. Beginner users won't understand, yet, how to set user preferences, so I recommend having them initially shown these covers. Chavey 18:15, 1 March 2014 (UTC)
I meant the background color. I should have said too bright, instead of saturated. The color "Moccasin" looks good.--Rkihara 01:22, 1 March 2014 (UTC)
OK, I have changed the background color to "Moccasin" and turned it into a User Preference. I will leave a note on Jack's Talk page to let him know that he will need to flip the flag in order to take advantage of this functionality. Thanks for the feedback! Ahasuerus 02:47, 1 March 2014 (UTC)
Much appreciated, that 'blue' was leaving spots in my vision!! .... not since the 60s .... ;-)). Now, when do those annoying little "?" balloons become optional??? Cheers! --~ Bill, Bluesman 03:52, 1 March 2014 (UTC)
It's on my radar screen, but, unfortunately, it's not as simple as it sounds. I need to implement 3 or 4 other FRs first because of various dependencies, but hopefully it will be done within a week or so. Ahasuerus 04:41, 1 March 2014 (UTC)

Patch r2014-120: Author image credits

The way images hosted by third parties are credited has been revamped. In addition to cover scans, author photographs are now credited and all credit links open in separate windows. Ahasuerus 23:24, 28 February 2014 (UTC)

It used to be that when I clicked on the credit for ISFDB-hosted images I was taken to its wiki page, which was VERY useful. Now I'm taken to the ISFDB front page, which is rather silly since I'm already on the site. Mhhutchins 03:37, 1 March 2014 (UTC)
Sounds like an unintended side effect. Let me take a look... Ahasuerus 03:50, 1 March 2014 (UTC)
Made a change and installed it, then realized that it's not what I intended to do. Back to the drawing board... Ahasuerus 04:13, 1 March 2014 (UTC)
OK, I think I got it now. Ahasuerus 04:39, 1 March 2014 (UTC)

Patch r2014-121: Quotes in searches

Regular and Advanced Search pages/boxes have been modified to recognize non-standard (Microsoft's and so on) single quotes/apostrophes. Ahasuerus 01:56, 1 March 2014 (UTC)

Temporary outage

Due to a backup failure overnight, I will need to re-run the backups at 9:30am server time. The whole thing should take about 10-15 minutes. Unfortunately, the server will be unavailable while the process runs. Ahasuerus 15:18, 1 March 2014 (UTC)

Patch r2014-126: Search changes

The way regular and Advanced Search handle leading and trailing spaces (which they used to treat differently) has been standardized. By default, leading and trailing are now ignored. A new User Preference, "Keep leading and trailing spaces when searching", has been added. If you turn it on, the search logic will respect all entered spaces. Ahasuerus 20:04, 1 March 2014 (UTC)

Changes to the backup schedule

We have had a lot of problems with the nightly backups lately. The problem is that the server can be very slow and even unstable at night (server time) and the backups are a very resource-intensive operation, so they can fail when the server is flaky. To ameliorate this problem, I have rescheduled the backups from 2am server time to 9:30am. Unfortunately, this means that the server will likely be unresponsive for about 10 minutes between 9:30am and 09:40am. Ahasuerus 14:54, 2 March 2014 (UTC)

What timezone is that? -- JLaTondre (talk) 19:33, 2 March 2014 (UTC)
The server is on US Central time. Ahasuerus 19:48, 2 March 2014 (UTC)

Patch r2014-127: Title Merge improvements

The Title Merge page has been made smarter. When displaying a list of to-be-merged titles, it should preselect earlier and more exact dates. For example, if title A is dated 2012-00-00 and title B is dated 2012-04-00, title B will be preselected. If title C is dated 2012-03-01 and title D is dated 2012-02-28, title D will be preselected. Similarly, when merging a title whose "storylen" value is "sf" with a title whose storylen value is anything else ("ss", "nvz", "nt", "nv", etc), the latter will be preselected. Ahasuerus 00:18, 3 March 2014 (UTC)

Thank you! Chavey 14:30, 3 March 2014 (UTC)
You are welcome :) Ahasuerus 20:04, 3 March 2014 (UTC)

"New lines" in Notes

Just a heads up that I am currently working on a patch which will change the way Notes are displayed. Once the patch has been installed, it will be no longer necessary to enter "<br>" to create a new line. Old "<br>"s (we have almost 85,000 of them!) should still work.

If you can think of any problems that this forthcoming change may cause, please post them here. Ahasuerus 05:35, 3 March 2014 (UTC)

This is probably obvious, but just in case: When a newline and a <br> are next to each other, it shouldn't add two newlines. Many editors put newlines before or after a <br> within the note fields. -- JLaTondre (talk) 22:33, 3 March 2014 (UTC)
That's right. There are other permutations that I am currently testing, e.g. <p> and [space]<li> followed or preceded by a newline. Ahasuerus 22:53, 3 March 2014 (UTC)
OK, I think I got it. Everything should work the same except for some very minor positioning issues when using <p>. Please note that you may need to press Ctrl-F5, which tells the browser to do a complete page reload, in order to make the new formatting work correctly. Ahasuerus 03:46, 4 March 2014 (UTC)
And BTW, the way the word "Note(s)" is spelled has been standardized. It should be "Note" going forward. Ahasuerus 14:15, 4 March 2014 (UTC)
It's not properly adding a newline when a <br> is the first thing (example example). -- JLaTondre (talk) 22:19, 4 March 2014 (UTC)
Sorry, the "strip all white space" logic was a tad too aggressive. Should be fixed now. Ahasuerus 01:16, 5 March 2014 (UTC)

Patch r2014-132: Note to Moderator added to Export/Import page

The software has been changed to allow adding a "Note to Moderator" when importing/exporting content. Please note that the new field appears on the second ("Import/Export Contents") page. Ahasuerus 17:26, 5 March 2014 (UTC)

Patch r2014-135: Publication listing changes

The Content display algorithm has been adjusted. It used to suppress the display of ALL container titles whose title type matched the type of the displayed publication. The new algorithm only suppresses the display of the FIRST container title that matches the type of the displayed publication. The result is that if, e.g., an anthology publication contains two ANTHOLOGY titles, then the second one will be displayed, which should hopefully result in an editor noticing and correcting the problem. Ahasuerus 01:16, 6 March 2014 (UTC)

Patch r2014-136: Most Popular Titles lists

The ISFDB Statistics and Top Lists page has been updated to include 7 "Most Popular Titles Based on Awards and Nominations" lists. Now we just need to catch up on 2011-2013 awards to make the lists more useful :) Ahasuerus 16:18, 8 March 2014 (UTC)

Not sure most popular and most awards is synonymous. But anyway, the webpage has a spelling error. -- JLaTondre (talk) 16:34, 8 March 2014 (UTC)
Well, Al's original awards-based lists were called "ISFDB Top 100 Lists", which I thought was no longer feasible since we had added other "Top 100" lists. However, I agree that "Most Popular" is not that great either. What would be a better word to describe these lists? Ahasuerus 16:48, 8 March 2014 (UTC)
"Titles Ranked by Awards and Nominations"? -- JLaTondre (talk) 12:32, 9 March 2014 (UTC)
Thanks, changes made. Ahasuerus 21:18, 9 March 2014 (UTC)
It says "...Awards amd Nominations". -- JLaTondre (talk) 16:34, 8 March 2014 (UTC)
Yes, I noticed the error right after I installed the patch :) Ahasuerus 16:48, 8 March 2014 (UTC)

Helping with broken cover images

If you have some favorite authors that you like to make sure their ISFDB data is just right, here's a suggestion that just became possible. For your author's titles, scroll down to glance at all of the covers of their books. (This is fun to do anyway.) If you see what appear to be blanks in the layout of covers, that's because a book has a link to a no-longer existing image. Click on the blank spot, and you'll be taken to the record with the bad cover image. Then you can try to find a replacement for it, and if not, just delete the bad link. Chavey 03:29, 10 March 2014 (UTC)

Or if you're a moderator, you can go to this clean-up script that lists all records with broken cover image links. This list at one time had more than 3000 records on it. 03:44, 10 March 2014 (UTC)
Using this list is a better method to finding broken links. For example, looking at this title, you wouldn't know that link to the cover image is broken. Click on the pub record and you'll see that it's not there, even though "officially" this is not a broken link. Now look at this title you can see that the cover image link is broken. All of the records with missing images can be found on the clean-up script, even those that aren't visible on the title record. Mhhutchins 03:48, 10 March 2014 (UTC)

Nebula Award description

This overview page for the Nebula Award states that it is an "International Award" but goes on to say it is awarded to the best work published in the United States. Isn't this contradictory? Mhhutchins 17:24, 11 March 2014 (UTC)

Good point. Locus used the phrase "Major Award" to refer to things like the Nebulas and Hugos; sets of awards that cover a broad spectrum of parts of speculative fiction. I couldn't think of a good name for awards that were generalist (i.e. not restricted to a subset of spec fic), and reasonably universal (i.e. not regional). I don't like the use of "Major Award", because we're not in the business of making qualitative judgements between different awards -- although Locus, arguably, is in that business. Plus, their use of "Major Award" has become quite bloated, and now includes 16 different awards. I would appreciate suggestions for a better name for such "inclusive" awards. I have tentatively change them all to "Multi-Category Awards"? Seems a bit wimpy to me, but the best I can come up with. Chavey 02:53, 12 March 2014 (UTC)

Also this description of the World Fantasy Award] states that it is a "Fantasy Award". Duh. Shouldn't it follow the same format as other award descriptions by giving the type of award (thematic, individual, national, international, publisher, etc.)? Mhhutchins 17:28, 11 March 2014 (UTC)

What I meant by "Fantasy" was "Sub-Genre (Fantasy)", for awards given in only one genre branch of speculative fiction. I have renamed all such categories along this rubric, i.e. "Sub-Genre (Science Fiction)", "Sub-Genre (Fantasy)", "Sub-Genre (Horror)", and "Sub-Genre (Alternative History)". Chavey 02:53, 12 March 2014 (UTC)

Same question about the International Fantasy Award and the Rhysling Award. Shouldn't we be consistent? Mhhutchins 17:28, 11 March 2014 (UTC)

Also, the Crook Award is not a "New Writer Award". It's awarded for the best first novel, not to a new writer. Mhhutchins 17:33, 11 March 2014 (UTC)

When I wrote all those "categories" for the original Wiki page (which Ahaseuras pulled into the new award format fields) I was trying to group awards according to some moderately broad categories. My hope is that as the list gets very long, that in addition to the alphabetical list we could provide a list of awards by categories such as these. The original Locus awards page did this, and my categories were largely based on theirs (except for "Major Awards", of which they only had 10 in those days). Finding groupings, and deciding which things go in which groups, can be helpful to a user, but certainly leads to classification problems. For example, does the Campbell memorial award go under "Sub-Genre (Science Fiction)" or under "Writing Form (Novel)", since the award goes to something in the intersection of those two groups? It may be that these classification problems are one reason why the new Locus awards page deletes almost all of those categories. Still, I did as best as I could. I'll mention that the Crook award, of which you complain, was listed in the Locus Awards under the "New Writer" category. And if you're trying to limit the number of groupings, IMHO, that's close enough. I hadn't looked at these for a couple of years, so Mike's comments made me go back and improve the consistency of these categories. For your interest, the current categories I have them listed under, with the "sub-categories" used, are as follows:
  • Multi-Category Awards
  • Writing Form Awards (Novel, Short Story, Poem, Screenwriting)
  • Sub-Genre Awards (Science Fiction, Fantasy, Horror, Alternative History)
  • Thematic Awards (Gender, LGBT, Libertarian, Race & Ethnicity)
  • YA Awards
  • Artist Awards
  • National Awards
  • Regional Awards
  • Individual Awards
  • New Writer Awards
  • Academic/Professional Awards
  • Publication-Specific Awards
I wonder if YA should be contained inside one of the other groups? I don't like the name "Individual Award" -- those are awards going to specific people (e.g. for overall contributions) instead of specific works, but I think that's an uninformative name. And if you don't see the value in finding some groupings like this, I suggest you look at the list of the 99 other awards we should probably add to our current list of 53. Chavey 02:53, 12 March 2014 (UTC)
My concern was less about how to categorize the awards than it was that there be some consistency in the categorization. I personally think that such categorization is even unnecessary, especially now that most of the data has been incorporated into the database. As long as the award is clearly (and correctly) described, there's no need to categorize it at all. Mhhutchins 03:59, 12 March 2014 (UTC)
I still think describing the Crook Award as a "New Writer Award" is incorrect. Paolo Bacigalupi won the award after ten years of professional sales. Paul Melko sold his first story at least 12 years before writing his prize-winning first novel. Mark L. Van Name had been selling stories for 17 years before winning the award. New writers? I don't think so.
Looking at your list of categories, I could imagine the Hugo Awards could easily be classified in at least six of them. Given my druthers, I'd do away with categorization entirely and just describe the damn things. Mhhutchins 04:12, 12 March 2014 (UTC)
A couple of thoughts.
First, one of the most popular features of ISFDB has long been this collection of "Top 100 lists" which Al last updated in 2005. If you enter "ISFDB " into the Google search box, the first selection in the drop-down list will be "isfdb top 100 novels". Or at least that's how it works for me -- Google search results are based on a number of criteria, including the IP address of the user.
When I started migrating these lists to the ISFDB proper a few weeks ago, I quickly realized that we had a problem. The four "Balanced Lists" were easy because the algorithm treated all award records the same way. However, the "Critical Lists" and the "Popular Lists" algorithms expected that all awards were either "determined by jury" or "determined by popular vote". That was easy to implement in the software back when we supported only a dozen (give or take) award types, but it wouldn't work too well going forward as we add more and more awards. At first I considered adding a new "Sub-Type" field to Award Type records, but this type of categorization has become more difficult with the proliferation of awards over the last couple of decades. I suspect that the best we can do is create an Advanced Search page which will let users assign weights to individual awards. Not a high priority, though.
One thing that I did do as part of the recent Award improvements was add two new fields to Award Type records: "Given For" and "Given By". They are displayed on the Award Directory page as well as on individual award overview pages and seem to cover much of the same territory that Darrah wanted to cover. Ahasuerus 19:31, 12 March 2014 (UTC)
On the presumption that "one picture is worth a thousand words", I restructured the Awards Wiki page along the lines of the categories I'm suggesting. Each award line would be replaced by the corresponding line from the normal Awards Page, and there would be a link on that awards page to this one, something like "Awards by Category". In this format, there's room to expand the description of the categories (which might satisfy Mike), and those categories would presumably be removed from the "Note" on each award page (which I KNOW will satisfy Mike). And while I appreciate Ahasuerus' "Given For" and "Given By" columns, that's still quite different than what I'm suggesting. (Again, remember that the list of awards is expected to grow to three times the current size, so each of those categories will become substantially more populated -- esp. the National Awards). Chavey 03:35, 13 March 2014 (UTC)

Question for current members of the Science Fiction Book Club

When was the last time you received a catalog in the mail? The last one that I received was the Holiday 2013 catalog on November 20. I've had a series of back and forth email conversations with them, in which they never fully responded to my inquiries about not getting the catalogs. They just keep saying I'll get the next one. Subsequently, I've not had to respond to the featured selections, and thankfully haven't received any unwanted books in the mail. Has anyone else had similar experience lately? Mhhutchins 20:48, 12 March 2014 (UTC)

I just received the Spring 2014 catalog in the mail today. I no longer have to respond to featured selections either, after I asked to discontinue my membership sometime last year. Albinoflea 04:33, 25 March 2014 (UTC)
Have you been receiving the mailed catalog on a continuous basis (roughly every three weeks)? Mhhutchins 06:42, 25 March 2014 (UTC)

Amazon images no longer linkable

Starting some time today, (since it worked yesterday), you can no longer get the URL of an image on Amazon. Or at least you can't until someone can figure out how to decipher the URL from the data which is now given when you try. The "address" of the image starts with "data:image/jpeg;" and not the typical "http://" Anyone up to the task? Mhhutchins 02:36, 14 March 2014 (UTC)

It must be 10 thousand characters long. Yikes!Kraang 02:53, 14 March 2014 (UTC)
The old URLs are still embedded in the HTML and can be extracted, although it takes some effort. For example, consider Reternity by Neal Wooten. The image URL is jpg . If you display the raw HTML underlying the Amazon page (usually Ctrl-U) and search for "51uuPaRW5vL", you will find it in 3 places. It looks like "imageGalleryData" has the most pristine version while "imageAssets.push" and the Pinterest section have additional adornments. Disclaimer: I have only tested a few ISBNs so far. Ahasuerus 02:54, 14 March 2014 (UTC)
Having an image of the publication on the ISFDB record isn't worth that much effort. Mhhutchins 16:25, 16 March 2014 (UTC)
I went to two books and control-clicked the cover image (right-click on Windows), then from the popup menu selected "Open Image in New Tab". (I used one "Look Inside" book and one without "Look Inside"). In both cases the image came up in a new tab with the simple URL for the image. I did the normal step of deleting the junk between the two periods, and got images exactly like what I'm used to seeing. I am using Chrome, so your mileage may vary with other browsers. Chavey 03:06, 14 March 2014 (UTC)
Could you please post the URLs of the two books? Ahasuerus 03:25, 14 March 2014 (UTC)
I just picked some random books, but here's one that I just used to add a cover to the database, and there's another example immediately following Kang's next comment. "Long JuJu Man" is available here on Amazon. I control-click (right-click) the image, selecting "Open Image in New Tab". I get this image. I remove the dot-to-dot stuff, and get this image. Then I added that image to our record of the book. No problems. Again, I'm using Google Chrome, so there is some slight possibility that what I'm seeing is not what you're seeing, but I have had no problems with any images. Chavey 14:44, 14 March 2014 (UTC)
Thanks. Curiously, I didn't get the same results when I followed the listed steps. The behavior was the same under Firefox and Google Chrome (both 33.0.1750.146 and 33.0.1750.149, the latest version), so it doesn't appear to be a browser issue. I suppose Amazon may be using the client's IP address to customize its pages... Ahasuerus 15:44, 14 March 2014 (UTC)
Look at the URL on this[1] I think it's a mistake at Amazon's end.Kraang 03:11, 14 March 2014 (UTC)
I'm not seeing what the problem is. I start at that page, ctrl-click and "Open Image in New Tab". I get this image. I delete the "dot-to-dot" stuff, and get this image, which is exactly what I would expect to see. Chavey 14:44, 14 March 2014 (UTC)
I noticed this a few days ago too, for the new version of Shaman that will be released later this year. Most books I've seen with the new-style "Look Inside" blue triangle overlay have the new data:image/jpeg links.
With these new links, the entire content of the image is encoded in the link itself in base 64. I suppose this means fewer server calls. While you can open the image in a new tab (right-click) and save that image, it ends up as a JPG with the "Look Inside" embedded in it. Using base-64 decoder sites like give the same result.
With Shaman I noticed that at least the tiny thumbnail in the "Frequently Bought Together" section is still being handled the same way, and you can remove the "Look Inside" with the same URL editing we've grown accustomed to. Same with Kraang's Country for Old Men example. Likewise, if I perform a search on Amazon that brings up the book, (search Kim Stanley Robinson in books, sort by publication date) the thumbnail in the search results is still using the old style links. Not sure for how much longer though... Albinoflea 04:59, 14 March 2014 (UTC)
Unfortunately, the "Frequently Bought Together" section is not always available :( Ahasuerus
All of the pages I've checked seem responsive to Ahasuerus' method as well. View the page source (CTRL+U, at least in Firefox) then do a search for imageGalleryData , then grab the first URL. Albinoflea 05:06, 14 March 2014 (UTC)
By the way, is still using the old style "Look-Inside" graphics, if that's what's causing some of the problems. Chavey 14:47, 14 March 2014 (UTC)
It's working as normal for me (IE 9, Windows 7). Right-click on the image + Properties shows the expected image URL in the Address part. I tried it with everything cited above, and they're all the same / normal. I wonder if they changed something, then reverted. --MartyD 16:28, 14 March 2014 (UTC)
While I was at work today I was able to normally access by the old-style URL the same Shaman image file that had been giving me the odd base-64 encoded URL at home. But when I tried it again from home here, I was still getting the base-64 URL.
I logged out of Amazon and cleared my browser cache, and was able to get to the traditional URL again. If anyone else is still seeing these links, I'd be interested to know if taking these two steps resolves the issue for you as well. Albinoflea 03:51, 15 March 2014 (UTC)
Under Firefox, clearing the browser cache didn't help, but logging out of my Amazon account did. Under Google Chrome, neither operation changed anything. Curiouser and curiouser... Ahasuerus 04:42, 15 March 2014 (UTC)
For what it's worth, I tried the same. Using Google Chrome, I logged out of my Amazon account, and it still gave me the unlinkable URL when I used the right mouse click "Copy image URL" method. Then I cleared out my cache: browsing history, download history, and cached images and files (keeping my cookies). It made no difference. I'm not going to give up Chrome just to be able to link an Amazon image file to an ISFDB record. Mhhutchins 16:25, 16 March 2014 (UTC)
Just curious, do you see the same behavior in Chrome if you are in an incognito tab? Albinoflea 20:45, 16 March 2014 (UTC)
Let's see... Yup, the "incognito" mode fixed the problem in Google Chrome. Based on Michael's description above, it sounds like it may be the cookies that do it. Ahasuerus 21:13, 16 March 2014 (UTC)
Incognito wouldn't work for me, because I did not, and will not, disable cookies. Mhhutchins 22:17, 16 March 2014 (UTC)
Well, you don't have to delete or disable cookies for all Google Chrome windows. You can open a separate "incognito" window (as described here) and access Amazon images within it. Granted, it's a bit of a hassle. Ahasuerus 22:21, 16 March 2014 (UTC)
I continue to try to replicate the problems others are having, and am being unable to. Every image you see a problem with opens flawlessly for me. I've added several Amazon covers in the last few days, and never seen a problem. Just in case it makes a difference, here's my configuration: Google Chrome 33.0.1750.146, cookies and javascript turned on, no particular extensions loaded except for adBlock. I am signed in to Amazon; I am not signed into Google. I haven't cleared my cache in weeks. Images in Amazon work completely normally using either "Open Image in New Tab" or "Copy Image URL", and whether I'm seeing the new blue "Look Inside" or the older one. I'm on a Mac using 10.8.5. I can't think of anything else that might be causing a difference between what happens to me and what happens to others. Chavey 23:29, 16 March 2014 (UTC)

(unindent) The problem in Chrome is that it is advertising to Amazon that it supports the "data:" protocol. You can prevent the behavior there by going into Settings, Advanced Settings, Content Settings (in the Privacy section), and then choose "Do not allow any site to handle protocols" (vs. the default that allows it). If you don't want to turn the whole thing off, you could leave the default and add * and * to the exceptions. End of factual statements. If it were me and my browser, I would turn this off and only enable it for specific sites upon encountering the need for it. --MartyD 23:51, 16 March 2014 (UTC)

I tried that and it didn't work for me. I even tried to set up exceptions but it wouldn't allow me to enter them in the box. Perhaps I need to close out Chrome and open it again. Mhhutchins 00:04, 17 March 2014 (UTC)
Still doesn't work. I don't know what I'm doing wrong. Mhhutchins 00:11, 17 March 2014 (UTC)
Sorry: You also need to clear the browsing history/cached page. Changing the settings does not cause it to realize the page it has cached doesn't match the settings. --MartyD 00:16, 17 March 2014 (UTC)
I had to clear Google Chrome's cookies as well as its cached images in order to get it to work, but everything appears to be OK now. Thanks! :) Ahasuerus 00:25, 17 March 2014 (UTC)
If you don't want to delete all of your cookies, you could just delete your cookie. Albinoflea 02:11, 17 March 2014 (UTC)
Sorry, Marty. I just can't get it to work. I've changed the handler settings, I've cleared my cache, I've logged out of my Amazon account. I still don't get the image URL. I am not willing to clear my Amazon cookies because I like the ease of check-out. If that's the only way I can get the image URL, it's not worth it. Mhhutchins 02:50, 17 March 2014 (UTC)
You could try clearing your cookies and then re-logging back in. I was seeing the data links a few days ago, but they are gone now whether I'm logged in or not (and I haven't changed any settings). I'm guessing Amazon is/was testing something and it was enabled for certain sessions. Once enabled for the session, it seems to stay enabled. But once a new session is created (whether logged in or not), it's not enabled. Though they could still be testing it and it's all the luck of the draw whether you get it or not. -- JLaTondre (talk) 13:01, 17 March 2014 (UTC)
That setting is for allowing web services to handle protocols (ex. using Gmail for mailto: links); not specifying which protocol a given site uses. It won't have any effect on this issue. -- JLaTondre (talk) 13:01, 17 March 2014 (UTC)
Yes, but it's changing Chrome's identification to Amazon (or to Amazon's javascript) somehow. I haven't run it through an analyzer or proxy yet to see what the difference is. --MartyD 00:22, 18 March 2014 (UTC)

Michael Connelly

Does anybody believe Michael Connelly's novels should be present? As far as I can tell, they are all non-genre. Most are tagged "non-genre" (though entered as novel and not as non-genre) and even those that aren't don't seem genre based on their Wikipedia plot summaries and on-line reviews. Also see Author:Michael Connelly. Thanks. -- JLaTondre (talk) 19:14, 16 March 2014 (UTC)

Only Chasing the Dime is marginal, but could be dismissed as a near-future thriller in which the scientific innovation is only a plot device for the action. Unless there's someone more familiar with his work that objects, I'd say get rid of all of them, but maybe leave this one. Mhhutchins 19:55, 16 March 2014 (UTC)

Given no objection to this or the previous conversation, I've deleted them all except Chasing the Dime. -- JLaTondre (talk) 12:28, 23 March 2014 (UTC)

Winston Science Fiction

FYI, Dirk and I have added 38 pubs to the Winston Science Fiction publication series. Since there is no question as to which pubs belong to this pub series, I am posting this update here instead of notifying the verifiers individually. Ahasuerus 00:13, 18 March 2014 (UTC)

Authors/Editors Ranked by Awards and Nominations

Various lists of "Authors/Editors Ranked by Awards and Nominations" have been added to the ISFDB Statistics and Top Lists page. Ahasuerus 04:02, 21 March 2014 (UTC)

You'd think it was a great decade for authors from Australia and New Zealand looking at the list for the 2010s. Nine in the top ten places! Could it be because there is a small group of authors that compete each year for the awards given in that region? Perhaps weighted scoring should be considered for certain regional awards. Mhhutchins 05:02, 21 March 2014 (UTC)
Yes, it's a known problem or perhaps a conglomerate of problems. First, our coverage of recent awards is spotty, which gives thoroughly covered awards (three cheers for our Australian editors!) more weight than they would have otherwise. Second, there are numerous specialized awards -- regional, thematic, etc -- which tilt the playing field. For example, there is an award for alternative history stories, but there is no award for time travel stories, hence alternative stories and their authors are likely to rank higher than time travel stories and their authors. Similarly libertarian and gender-bending works are likely to appear higher on these lists because there are specialized awards for them.
I have experimented with a few different approaches to leveling the field, but the best I could come up with was an Advanced Award Search page where users would assign weights of their own, although defaults would be provided. The task was assigned to Bill Longley, but he was already too sick to work on it.
For now, the software doesn't discriminate based on award type with one exception. Prometheus awards and nominations are counted only once per title because the Prometheus Hall of Fame rules allow works to be re-nominated repeatedly until they win -- see, e.g., The Lord of the Rings. All other awards and nominations are counted independently even if the work was nominated for the same award in different categories, e.g. see the 2005 Quill Awards. Ahasuerus 06:21, 21 March 2014 (UTC)
I suspect that the correlation with Australian authors is partly a result of my having just finished entering all of the Hemming awards. Another complicating factor is the size of the nomination list. Being nominated for a Hugo is a big deal. In some years, being nominated for the Hemming just meant that ONE person had suggested the book be considered by the jury. Big difference. And with the Hemming (race, gender, sexuality, class and disability in Australian spec fic), the collection of candidates is modest, and some of the authors get nominated for several things they wrote that year. For example, look at the 2010 nomination list. Chavey 17:31, 21 March 2014 (UTC)

Herman Hesse

Do we happen to have Hermann Hesse experts who might be able to determine which of his novels are NONGENRE? Ahasuerus 14:19, 21 March 2014 (UTC)

I'm no expert on Hesse. The Dutch bibliography (Fandata) only mentions Das Glasperlenspiel and some of his fairy tales. --Willem H. 15:41, 21 March 2014 (UTC)
The Glass Bead Game is the only overt speculative fiction novel by Hesse that I'm aware of. But judging from the titles of the three collections, they all qualify for inclusion. And according to SFE3, five other novels also qualify. I would suggest using them as the source to change the other titles to NONGENRE. Mhhutchins 15:54, 21 March 2014 (UTC)

Server issues 2014-03-21

The server has been sporadically slow/frozen this afternoon (server time.) I have made some changes, which will hopefully help alleviate the issue. Ahasuerus 23:38, 21 March 2014 (UTC)

It was that way yesterday as well. From 12:00 until 1:30 [Mountain time ... server is on Central time??] managed only 12 simple edits in 93 minutes. Then it seemed better after about 3PM --~ Bill, Bluesman 22:30, 26 March 2014 (UTC)

Henry Gade

I've been asked to leave this subject here for discussion. I have the facsimile reprint of Amazing Stories, February 1942 and I listed the contents of it, but I listed the short piece by the pseudonymous Henry Gade as a short story. This is a full, pulp sized, one-page scenario that describes Gatos, a city in a crater of Ganymede, it also goes into some details about the society of catwomen, as catmen are rare, they are disemboweled by the females. While not a true short story, it is a fiction, after all, the catwomen in Gatos don't really disembowel all of the males of the species. However, since Henry Gade is a house name, pasted onto all sorts of things, should these pieces be listed as short fictions, they are listed as such when reprinted, or as essays, or, as I recommend, should they be judged on a piece by piece basis? As they have no basis in reality, I've always thought of them fictions even if not proper "short stories". MLB 22:09, 23 March 2014 (UTC)

(I moved this from the talk page (for discussion about the page) to this one, the discussion ("project") page. Mhhutchins 22:41, 23 March 2014 (UTC))

It's a non-fact essay, but since we don't have that type in the database, it could be classified as either ESSAY or SHORTFICTION, depending upon which is more prevalent in the piece. As the primary verifier of the record, we'll leave that to you. If there are other primary verifiers, then it should be discussed among you. If no compromise can be reached, check for any reliable secondary sources, like Tuck, Day, Miller/Contento. If not, toss a coin. :) Mhhutchins 22:47, 23 March 2014 (UTC)
Part of a continuing long debate, of which I think the most recent full discussion is in Rules & Standards 2008. A more recent, but less comprehensive, discussion is Community Portal 2010. The general conclusion has been, AFAIK, that such items are listed as short-fiction (but with no storylength attribute), and a Note is added that it is an "in-universe essay". There is a long outstanding Feature Request to add another "short fiction" type "fe", which stands for (depending on the editor, or the particular example of its use) "Fictional Essay", "Fake Essay", "Fictitious Essay", or "Facetious Essay". Eventually that will happen (I assume), and then a project will be created to try to find and re-categorize those items. That project will begin by searching for "in-universe essay" amongst the Notes (and the various "FE" terms above). So, include the note now; the database will catch up to it eventually. Chavey 23:15, 23 March 2014 (UTC)
Yes, this feature was requested awhile ago, but note all the other title types and sub-types requested on the same page.
Currently there is a dozen places in the code where novellas, novelettes and short stories are handled as special cases. Adding even more special cases to support other (sub-)types would make the software unmaintainable. What we need to do is streamline the code so that it would be easy to add additional types and sub-types. Ahasuerus 00:38, 24 March 2014 (UTC)

Tagging enhancement

Add Quick Tag and Tag Editor have been enhanced to re-display the Title Web page without flickering or requiring user interaction. Ahasuerus 04:25, 24 March 2014 (UTC)

Power Play by Ben Bova - Non-genre?

I'd be surprised if I was the only one who has read this book, although it seems that so far, no one else has verified a copy. I'm curious as to why it is marked non-genre. Briefly, the book is set in the very near future, and describes an Assistant Professor who is persuaded to be a science adviser to a man who wants to run for the Senate. The aspiring Senator needs an issue to enhance his campaign, and the prof comes up with power generation using MHD, on which his university happens to be doing research. The concept of using MHD to generate power isn't new, but I don't know of any serious claims that it will work, and be cost effective, so that part is fiction, even though there is plenty of science described. The politics is also fictional, which makes the book kind of a 'thriller', but I wouldn't kick it out of the SF category just for that reason. Finally, Bova's been writing fiction since 1959, and I've read about 98% of it, and I don't think that anything else he's written could be considered non-genre. —The preceding unsigned comment was added by Sjmathis (talkcontribs) .

One way to handle this case would be to change the title type to NOVEL and add a brief synopsis. That way our users could decide for themselves whether it matches their definition of SF. Ahasuerus 22:44, 24 March 2014 (UTC)
Judging from your synopsis I'd say that there is really enough speculation involved, to change the title to NOVEL. Stonecreek 07:20, 25 March 2014 (UTC)
(Apologies for forgetting the signature) - How does that take place? Doesn't seem to be something I can do. Thanks, Jack Sjmathis 12:16, 28 March 2014 (UTC)
Sure you can! Just take a heart and edit the title: change the title type to NOVEL and enter a synopsis if you like. Then also edit the publication(s) and change the title type for them also. Christian Stonecreek 13:23, 28 March 2014 (UTC)
I am afraid the distinction between NONGENRE and NOVEL title types is only valid at the Title level at this time; publication records cannot be NONGENRE. (Eventually we'll want to allow NONGENRE collections, anthologies, etc, but at the moment only novels can be NONGENRE.) Ahasuerus 15:10, 28 March 2014 (UTC)

Marvano or Mark van Oppen as canonical author?

See here for Marvano with already lots of variants as only by Mark van Oppen. I personally would be in favour of the legal or fuller name of a given artist, if he has - as in this case - published substantially under that name. But these publications in the mean were in German, whereas the output in his home language Dutch were mainly as Marvano. So, please join the discussion. Christian Stonecreek 07:35, 27 March 2014 (UTC)

I'd go with Marvano and not just because I will have wasted a lot of time varianting to what a previous editor had already established as being the canonical name. If, as you say, that's how he's known in his native language, let's stick with it. Mhhutchins 07:53, 27 March 2014 (UTC)
I also see that the Wikipedia article is given in that name and that he is better known as "Marvano". That seals the deal for me. Mhhutchins 07:55, 27 March 2014 (UTC)
I agree with Michael, the graphic novels based on Haldeman are credited in France to Marvano. Hauck 14:52, 27 March 2014 (UTC)
I don't think he ever published anything in Dutch as Mark van Oppen. He's been known as Marvano from his first published illustrations in the Dutch Orbit (not yet in the database, but will be someday) and his adaptation of Niven's Flight of the Horse. I think Marvano should be kept as canonical name. --Willem H. 15:23, 27 March 2014 (UTC)
Okay, that's fine! I'll go for the varianting to Marvano. Thanks! Stonecreek 04:04, 28 March 2014 (UTC)

Changing author's photographs

I've put on hold this submission that intend to change the present photograph we use for Vance's page. I was wondering what was the interest of such changes and was afraid that such changes, if repeated, may lead to some kind of wikipedia situations were evereyone want to have their best-liked photo of the subject illustrating an article. What are the thoughts of the community on the subject of changing such photographs (note that, in this case, Vance's physical appearance is quite the same) ? Hauck 14:59, 27 March 2014 (UTC)

I agree. No need to get into a photo war. But in this case, there's also a matter of permission/copyright violation. I've left a message on the submitting editor's talk page. Mhhutchins 16:03, 27 March 2014 (UTC)

Award bibliographies and pseudonyms

The Award Bibliography page has been changed to show the awards associated with the current author's pseudonym(s). For example, Alexis A. Gilliland's Awards page shows a couple dozen awards and nominations even though all of them are currently associated with "Alexis Gilliland". Ahasuerus 02:58, 28 March 2014 (UTC)

Thanks much! Chavey 03:57, 28 March 2014 (UTC)

Conditionally Human and The Darfsteller by Walter M. Miller, Jr. are actually novellas

In both cases a change from novelette to novella length seems due. See here for a discussion regarding Conditionally Human. It seems possible that this anthology published an even more abridged version than at its first appearance - judging from a cross reference reading of two German publications; the canonical text however is clearly above the threshold of novella length, I'd think.

The same holds for The Darfsteller, where we have the possible hinderance that it has been awarded a Hugo Award as Best Novelette. But as there was no difference made between novelette and novella in that year, it should be possible to change the length nevertheless. Or would the link break down when doing so? Stonecreek 05:55, 30 March 2014 (UTC)

Luckily, no changes to title data should affect any award links. Ahasuerus 06:11, 30 March 2014 (UTC)
See my response on Markwood's talk page. I did an estimated word count of "Conditionally Human" and it came to over 21,000 words. "The Darfsteller" is even longer. Both are definitely novellas. Mhhutchins 06:13, 30 March 2014 (UTC)
Unless a primary verifier is willing and/or able to do a word count or a comparison with the Galaxy printing, I would suggest that the note in this record be removed. It's not recommended that page count be used to compare the length of one printing of a story to another. There are many, many other factors that determine word count. Mhhutchins 06:24, 30 March 2014 (UTC)
Okay, I have removed the part on Galaxy. I hope it fits now. Stonecreek 06:41, 30 March 2014 (UTC)
Does the note come from a statement in the publication that the story has been abridged? Mhhutchins 07:09, 30 March 2014 (UTC)
No, it's from a parallel reading of this and a later version. Stonecreek 09:13, 30 March 2014 (UTC)
Good. Adding that information to the note would keep sticklers like me from questioning it. :) Thanks. Mhhutchins 17:27, 30 March 2014 (UTC)

100K moderations, a personal milestone

I have moderated more than 100,000 submissions by other editors. In the past, I've left it to Bill Longley to point out such milestones. But in his absence, I'll have to toot my own horn. Beep beep. Mhhutchins 22:17, 1 April 2014 (UTC)

Congrats! I'm impressed. Well above the rest of us. Thanks for doing so much of it. -- JLaTondre (talk) 22:43, 1 April 2014 (UTC)
Congratulations! BTW, Fixer asks me to say that he is very happy to be referred to as one of the editors, even by implication :-) Ahasuerus 02:15, 2 April 2014 (UTC)

Title Vote changes

The Title Vote page has been updated to allow removing erroneously cast votes. In addition, the appearance of My Preferences, My Web Sites and My Language Preferences has been enhanced in various ways without changing the underlying functionality. Ahasuerus 00:46, 8 April 2014 (UTC)

Mouseover help made optional

The mouseover help and all "question mark bubbles" have been made optional. You should be able to disable them by setting the "Do not display mouseover help on Edit pages" flag on the User Preferences page. Ahasuerus 03:16, 8 April 2014 (UTC)

Thanks for giving us the option. I just changed mine. BTW, what does the "Suppress translation warnings on Author Bibliography pages" actually do? I've never noticed that preference before. Mhhutchins 20:51, 8 April 2014 (UTC)
It disables the "Showing all translations (can be changed via My Languages under My Preferences)" message at the top of Bibliography pages. Ahasuerus 00:28, 9 April 2014 (UTC)

Windy City Pulp Convention

Anyone attending the Windy City Pulp Convention in Chicago (Lombard) starting on the 25th this month? If so are you interested in meeting up?--Rkihara 19:08, 14 April 2014 (UTC)

More awards-related changes (patch r2014-163)

A new "Award Details" page has been added. It's not very fancy, but it let me consolidate all of our "Edit Award" and "Delete Award" links on the same page. It will also facilitate adding the "Link Award" option when the functionality gets implemented.

The new page can be accessed from Award Year, Award Bibliography and Title pages by clicking on the value (asterisk or poll position) of the "Link" column, e.g. see Gene Wolfe's Award Bibliography page. I don't really like how it looks, but I couldn't think of a better solution. Suggestions are more than welcome!

A number of other minor things have been tweaked on award pages, but they should be self-explanatory.

There are two new moderator-only cleanup scripts, "Awards Associated with Invalid Titles" and "Suspect Untitled Awards". Some of the problem awards can be fixed right away, but many will require linking untitled awards to Title records, which currently requires deleting and re-entering the affected award. The process will be automated in the next patch, so moderators may want to postpone that part of the cleanup until the new (re)linking option becomes available. Ahasuerus 21:55, 16 April 2014 (UTC)

What happened to the link to edit or delete an award? Or has something changed since the last time I did any award edits? Mhhutchins 03:25, 17 April 2014 (UTC)
Oh, I see what you did. It just makes more sense to me to edit an award from its title, and not from a link on the author's award page. There's nothing intuitive about clicking on an unlabeled asterisk if you want to edit an award. Mhhutchins 03:30, 17 April 2014 (UTC)
I am not happy with the "asterisk solution" myself, I just couldn't think of a better way to accommodate different scenarios, including what will happen once award linking has been added :( I'll sleep on it and see if I can do better in the morning. Ahasuerus 04:21, 17 April 2014 (UTC)
The "Awards" section of the Title page has been changed to use a more tabular format, e.g. see Neuromancer, and the asterisk has been changed to the word "Details". However, the "Award Bibliography" page still uses asterisks (see, e.g., William Gibson Award Bibliography page) because dozens of occurrences of the word "Details" seemed too busy, but there is got to be a better way to do linkage. Perhaps move the "Place" column all the way to the left and link its values to the Award Details page, similar to how it currently works on the Year Award page, e.g. 1982 Locus Poll Award? (I'll tinker with it some more after I take another nap.) Ahasuerus 12:47, 17 April 2014 (UTC)
More tweaks have been applied. Ahasuerus 13:45, 17 April 2014 (UTC)
A question: how does one repair those "awards associated with invalid titles". I go to edit it and I can find nothing there that allows me to link it to a title record. The only option I can see is to create a new award directly from the title record and eliminate the "unassociated" one. Mhhutchins 03:35, 17 April 2014 (UTC)
The ability to link an untitled award to a title record (or relink an incorrectly linked award) will be added in the next patch. Ahasuerus 04:21, 17 April 2014 (UTC)
Thanks. I gave up trying to work on the clean-up scripts after the first one. Mhhutchins 04:25, 17 April 2014 (UTC)

(unindent) The way awards and nominations are displayed has been tweaked yet again. No more asterisks! :-) Ahasuerus 02:14, 19 April 2014 (UTC)

Campbell Memorial Awards and "Finalists"

Campbell Memorial award records have been cleaned up and a new "special" award level for "Finalists" has been added. We still need to reconcile award years 2011-2013 with the main award page. Ahasuerus 20:14, 17 April 2014 (UTC)

2011-2013 done. Ahasuerus 21:05, 17 April 2014 (UTC)

Proposed title page changes

There is a feature request to change the way publications appear on Title pages. Here is what the requester appended to the FR as an example.

The details would need to be hammered out, e.g. we'd want to change "Cost" to "Price" and merge "Type" and "Cat.", but I like the overall approach. It would also go well with the recent change to the way awards appear on Title pages, e.g. see the Neuromancer record. Would this work for everybody? Ahasuerus 01:24, 20 April 2014 (UTC)

It's looks strange at first because it's so different, but it started to grow on me. It's easier to read each publication listing. I assume the green check is for primary verified records. I have no objection to the change. Mhhutchins 02:38, 20 April 2014 (UTC)
If there's a column with 'Pages' or 'Page count' it seems redundant to put 'pp' after the number. --~ Bill, Bluesman 05:17, 20 April 2014 (UTC)
That's a good point. Ahasuerus 11:35, 20 April 2014 (UTC)
Also, if the column for 'Verified' gets only a check mark, couldn't there be another column for Images, which would accommodate the recent [optional] change? --~ Bill, Bluesman 05:17, 20 April 2014 (UTC)
Sure. Pretty much everything that is currently displayed in the "Publications" section of the Title page will be available in the new version. Ahasuerus 11:35, 20 April 2014 (UTC)

(unindent) It took a bit longer than expected because Firefox handles certain types of tables in a rather counter-intuitive way, but the deed is done now. I suppose we may need to give it a couple of days to sink in and then we can tweak it. Ahasuerus 04:12, 22 April 2014 (UTC)

Looks fine. I like it a lot. Mhhutchins 04:20, 22 April 2014 (UTC)
First "live" impression is we've become a spread-sheet. I suppose it may look better in the daylight ..... ;-) --~ Bill, Bluesman 04:37, 22 April 2014 (UTC)
Me, I like spreadsheets. Easy to read up-and-down and across. Easy to compare one publication with another. Less stress on the eyes and the brain. Mhhutchins 05:00, 22 April 2014 (UTC)
I find the "ISBN/Catalog#" column to be too wide with too much redundant space to the right of the ISBNs, and when I contract the page so it doesn't fill the entire width of my screen the "Pages" column contracts so much that the "s" and the page numbers themselves have to appear on a second line, while there's still all that unused space after the ISBNs. I'm using Safari 5.1, so it may display better with other browsers. Otherwise, yes, easier on the eye all round, and I expect I'll get used to it rather quickly. PeteYoung 06:22, 22 April 2014 (UTC)
The thing about the "ISBN/Catalog#" column is that it needs to be able to accommodate catalog IDs, ISBN-10s and ISBN-13s, so the range is anywhere from 0 to 17 characters. I could change the display logic to let the browser determine the width dynamically, based on the longest string in each column, but, unfortunately, that makes the table look funky in other ways. Perhaps there is a compromise solution, but I haven't been able to find it yet. Ahasuerus 12:04, 22 April 2014 (UTC)
As far as Bill's comment goes, well... It is possible to turn this into a User Preference to accommodate both listophiles and tablemaniacs :) But let's wait a bit and see what other folks think. Ahasuerus 12:30, 22 April 2014 (UTC)
The more User Preferences, the better! I'd like to see the display of Awards and Reviews optional as I completely gloss over both. My 'spread-sheet' comment stems from the look, not the functionality. The DB had a unique look, now it really doesn't. And, only in those terms, seems like a step sideways. Everybody will get used to it, even me, but the look is gone. Maybe it's because my ex-wife was an accountant and that's what spread-sheets remind me of ....... ??¿¿?? ;-))) --~ Bill, Bluesman 23:31, 22 April 2014 (UTC)
There is a Feature Request to make the display of Reviews optional. I'll see if I can bump it up. Ahasuerus 03:26, 23 April 2014 (UTC)
At least Reviews are at the bottom of the page. Awards are at the top. Just one more thing to scroll through there. --~ Bill, Bluesman 23:53, 23 April 2014 (UTC)
Can you force a break in the page number field after the "+"? I've seen it broken between numbers, e.g. "xiv+3" over "36" for a record given as "xiv+336". Mhhutchins 17:08, 22 April 2014 (UTC)
Done! Ahasuerus 18:57, 22 April 2014 (UTC)

(unindent) The spacing needs work. Look at I, Robot. Even when I maximize it on a widescreen monitor, most fields have too much whitespace and the publisher field is limited so that it wraps. It might be best to parse each column to find the maximum characters and dynamically set the width based on that. That could help with the ISBN size mentioned above. Also, is the "Verif" heading intentional? -- JLaTondre (talk) 20:21, 22 April 2014 (UTC)

Well, server-side parsing is certainly doable, but it feels like breaking the Web model where the browser is responsible for these kinds of things. I'll have to play with it some more... Ahasuerus 03:26, 23 April 2014 (UTC)
Setting column widths already limits the browser's control. It's a question of whether the widths can be set smarter. -- JLaTondre (talk) 22:06, 23 April 2014 (UTC)
Going back to the tabular display: I've love to be able to sort by any of the fields, but then that would be a spreadsheet. (And nothing wrong with that!) Mhhutchins 21:24, 22 April 2014 (UTC)
Actually, sortable HTML tables are theoretically an option. It will require the use of third party libraries and JavaScript will need to be enabled, but it's doable. Ahasuerus 03:26, 23 April 2014 (UTC)
If you want to go for broke, you could also make them filterable. ;-) There are libraries for that as well. -- JLaTondre (talk) 22:06, 23 April 2014 (UTC)

Linking to IMDB records

I've not worked much on awards, but have noticed that every award for a film or TV episode (that I've checked) is incorrectly linked. The field is supposed to be for the IMDB record number, but all of them have been linked to titles, which pulls up a list of matching titles on IMDB, not linking directly to the IMDB record for that film or TV episode. Was this the way it's supposed to work? Look at the nominees for the 2014 Hugo, for example, Frozen. Now look at one I fixed: Gravity. I think the way the entry field is titled could have added to the problem. It's labeled "IMDB title". Perhaps if it had been titled "IMDB record number" there may not have been a problem. Mhhutchins 04:10, 22 April 2014 (UTC)

I am not sure I remember all of the details, but I think that IMDB URLs have changed over time, possibly more than once. Our software has tried to keep up with them, but it's been a moving target. I'll have to review the code to see what it's currently doing and perhaps enhance it. Ahasuerus 12:35, 22 April 2014 (UTC)
I'm the one who entered those awards and I was following the advice from this help page which specifically requests that the title be used. Interestingly, the edit help (as opposed to the add) suggests that this field not be used at all, though it is using the label "Movie URL". Once we decide how the field should be entered, we should definitely get these help files in synch with what the software expects. --Ron ~ RtraceTalk 15:23, 22 April 2014 (UTC)
Actually both of those help pages are wrong. You don't even have to enter the full URL, just the record number, starting with "tt". There are probably dozens of help pages where the software changes aren't reflected in the help documentation. Hopefully, one day someone will have the time to go through them all. In the meantime, I'm too busy moderating the queue, and training new editors to work with the software as it currently works without having to send them to help pages which may not be correct. (That's how I learned from those who mentored me, but that doesn't seem to be the right way, even if it's become the only way.) Mhhutchins 17:29, 22 April 2014 (UTC)

Separating VTs from translations on the Title page

At one point we briefly discussed the following Feature Request:

  • We would like to separate VTs from translations on the Title page. Ideally, the display order will be as follows:
    1. VTs whose language is the same as the language of the canonical title.
    2. Magazine appearances where the language is the same as the language of the canonical title.
    3. VTs whose language is NOT the same as the language of the canonical title.
    4. Magazine appearances where the language is NOT the same as the language of the canonical title.

It seems like it would be useful, especially when displaying a title with a lot of VTs and translations like The Wonderful Wizard of Oz. It would also be fairly easy to implement. However:

  1. Wouldn't having up to 4 sections (as listed above) be excessive?
  2. Over 60% of our title records still do not have a language code assigned to them, so they could end up being incorrectly categorized.

Any suggestions re: the best way to tackle this? Ahasuerus 12:26, 22 April 2014 (UTC)

The only thing I can suggest is to change all non-languaged records to English. Then leave it to editors to make changes in the incorrect records, which I can't imagine being more than 5% of the total. (I believe there were relatively few translated title records entered before language was added to the software.) Otherwise, I can't see this working at all. As to your question about the four sections being too excessive, it all depends upon how they're displayed on the page. Until we can see a mock-up, it's going to be hard to know. Also, there's going to be a relatively small number of records that will have all four, probably just the popular titles by the well-known authors. Even then, magazine appearance of novels is a dying breed. Mhhutchins 17:14, 22 April 2014 (UTC)
I have run a few searches and it looks like things are still too unsettled to separate regular VTs from translations with any degree of certainty. We may want to start by creating a cleanup script that would look for authors whose working language is not English and whose works haven't been assigned a language code. I'll see what I can do... Ahasuerus 03:13, 23 April 2014 (UTC)
Last year I corrected the language on about two thousand non-English titles. I started with all existing non-English titles, looked at their publishers, included all non-English language publishers known to Wikipedia, then looked at all books published by those publishers. For each such book I evaluated the language of that book, and also looked at any other non-English VT's of such books (assuming that books translated into one language were the ones most likely to be translated into other non-English languages). So I at least made a start on identifying non-English VT's. As Ahasuerus notes, this was certainly not all of them, though. Chavey 12:55, 23 April 2014 (UTC)
It certainly sounds like a good start! :) In the meantime, I have added a new cleanup script, "Prolific Authors without a Defined Language", which shows the top 300 authors without an associated language code. Ahasuerus 19:05, 23 April 2014 (UTC)
Setting a language for an author doesn't automatically set the language for titles already in the database. Or does it? Otherwise, I don't see the point of setting a language for an author. Or are there other reasons to do so? Mhhutchins 21:06, 23 April 2014 (UTC)
Sorry, I didn't make it clear where I was going with this. The idea was to go for the low hanging fruit since there are fewer author records than title records. Once most of the "prolific" authors have been updated, we'll be in a better position to create other scripts leveraging their language data. For example, we could create a script called "Display a list of authors with a defined working language and titles with no language code". Clicking on a "Resolve This Author" button would assign the author's language code to all of his or her titles that are currently language-less. I am a little hesitant to automate the language assignment process since so many permutations are possible, e.g. see Eddy C. Bertin's, Nick Perumov's or Sam Lundwall's bibliography pages, but I guess we'll cross that bridge once we get there. For now, there are additional benefits as you note below. Ahasuerus 23:50, 23 April 2014 (UTC)
I see one thing it accomplishes: if a title record is set in another language other than the one set for the author that language will be displayed on the author's title page. Good deal. Mhhutchins 21:19, 23 April 2014 (UTC)
Maybe I'm wrong, but I've been assuming that an author's "working language" is the one that new books by them default to; and no more. So that if I create a new title by "Élisabeth Vonarburg", it will initially assign the language as French; unless I manually change it. And if someone primarily writes in Russian, expressed by us as "works in" Russian, and the ISFDB editor does nothing to change it, the assumption is that this newly entered work is in Russian -- instead of our old-fashioned way of assuming everything is in English unless told otherwise. Chavey 13:53, 24 April 2014 (UTC)
Sorry, that's an incorrect assumption. When you enter a book it defaults to the language you set under "Editing" in your preferences. Otherwise you have to change it in the proper field. Click on "Add New Novel" to add a work by Vonarburg and you'll see the language of the publication is set before you enter one character. Mhhutchins 16:16, 24 April 2014 (UTC)
That's right, the only thing that "Working Language" does at this point is prompt the Summary Bibliography page to display a canonical title's language in square brackets if it differs from the "Working Language" of the author. Ahasuerus 18:33, 24 April 2014 (UTC)

[unindent] Another question: why should artists have a set language? If I change Paul Orban ("Orban") to Hungarian as his native language, all of his artwork in English publications will be appended with "[English]". Artwork actually has no language. Can the software be amended to drop the language field from artwork title records, both COVERART and INTERIORART? Mhhutchins 21:27, 23 April 2014 (UTC)

It's certainly possible, but let's consider the implications for various Web pages first. For example, Patrick Woodroffe did the cover for the 1974 Pan edition of Heinlein's The Green Hills of Earth. In 1980 it was reused by Bastei Lübbe when they published Panshin's Welt zwischen den Sternen (Rite of Passage). Our title page for the COVEART record shows the language of the Cover: Welt zwischen den Sternen record, which seems to be desirable. Would you agree? Ahasuerus 00:05, 24 April 2014 (UTC)
No. As I said above, art has no language. Its title is based solely on the work it illustrates regardless of the language, an arbitrary title based on ISFDB standards. I see no problem with a COVERART record having no set language and any publications of same pieces of art would be merged (if they have the same title) or varianted (if they differ). Mhhutchins 02:14, 24 April 2014 (UTC)
Although it would be possible to make an exception for COVERART titles and make them language-less, it would make the related software noticeably more complex and harder to maintain. It would be easier to suppress the display of language information for COVERART records. Before we go any further, though, what about INTERIORART records? Maps, diagrams, etc can have a non-trivial amount of language-specific information as anyone who has ever tried to use a Bulgarian map can confirm :) Ahasuerus 19:22, 24 April 2014 (UTC)
Library of Congress uses a special language code, zxx, to indicate an item has no linguistic content. Don't know why we couldn't do something like that here and have COVERART default to that. Albinoflea 02:35, 25 April 2014 (UTC)
I like it. Mhhutchins 03:21, 25 April 2014 (UTC)
A variant relationship is based on a change in the title of the work they illustrate, not the language of the title or the work they illustrate. Mhhutchins 02:14, 24 April 2014 (UTC)
Oh, I see. So if we had a COVERART record for "Ubik" (or "1984", "Solaris" or some other book whose title doesn't require translation) and it was re-used by German, French and Dutch publishers, you would suggest that we merge the title records instead of creating VTs as long as the title of the book was not changed, right? That sounds workable although the scenario is relatively uncommon. Ahasuerus 19:22, 24 April 2014 (UTC)
Yes. It would be unnecessary to variant a record for the same cover art for the same titled work, since the artwork itself has no language. In these cases the titles could be merged. But that is such a tiny fraction of what would happen if we choose to make COVERART and INTERIORART records non-languaged. For example, you wouldn't have the awkward display of the art credits in this publication as being "translations" of another work of art. And you wouldn't have a situation like this artist as was discussed. (I changed his "language" to Hungarian just to illustrate the point.) Mhhutchins 03:21, 25 April 2014 (UTC)
Now, using the rules that you described above, the "Cover: The Green Hills of Earth" page would still show a VT for "Cover: Welt zwischen den Sternen" except that it wouldn't say "[German]" next to the title, right? It seems like in most cases it would make the page slightly less useful. Ahasuerus 19:22, 24 April 2014 (UTC)
P.S. One more thing about Orban. The term "Working Language" was chosen specifically to get around this issue -- there are lots of people like Joseph Conrad whose first language was X, but whose working language was Y. Ahasuerus 00:25, 24 April 2014 (UTC)
There wouldn't be a problem if we didn't have to assign artists a "working language". Saying that an artist "works" in a language is ridiculous when you think of it logically, since their work has nothing to do with language, written or spoken. It's like saying an author works in colors. Mhhutchins 02:14, 24 April 2014 (UTC)
Well, the thing about artists is that they can also be responsible for essays, non-fiction works and even fiction, so there is no easy way to separate them from other types of authors. Ahasuerus 19:22, 24 April 2014 (UTC)
But it should be easy to separate types of records? I would think that a program could be written that searches for record types like COVERART and INTERIORART and have them handled differently. Give an artist a "working language" if you must, but surely exceptions can be made based on types of records. Mhhutchins 03:21, 25 April 2014 (UTC)
We could relatively easily suppress languages for COVEART titles, though, as discussed above. Ahasuerus 19:22, 24 April 2014 (UTC)
That would be a great start. I still think we'd should do the same for INTERIORART records. Because maps are disambiguated (or should be if the editor entered them correctly), we could make an exception for INTERIORART records with "(map)" in the title. Mhhutchins 03:21, 25 April 2014 (UTC)
Treating "(map)" as an exception wouldn't handle cartoons, diagrams, etc. It appears we have about 4000 cartoons entered as InteriorArt, and I would hazard a guess that many of them are "pure" cartoons, with no language content, while others have language-specific content. If we code "(cartoon)" or "Cartoon:" as special exceptions, like maps, then we'll never be able to list a pure cartoon as "no language", but if go the other way and assume all cartoons are language-free, then we would never be able to note a language when it's used. It seems to me we might be better off to use Albinoflea's suggestion about a special language code for "No textual content", which would allow a conscientious editor to enter a cartoon as "German" or as "No language", as appropriate. Chavey 06:23, 25 April 2014 (UTC)
We're actually saying the same thing. You're just talking about entering any language-free records starting now. I'm trying to figure out how to go back and change the thousands of language-free records already in the database. Mhhutchins 12:05, 25 April 2014 (UTC)
Then we're in complete agreement. That first pass, to get a decent approximation of "has / doesn't have" language can only be an approximation, but it would be a good start. And I suspect that cartoons should probably default to "has a language". Chavey 14:37, 25 April 2014 (UTC)

(unindent) It sounds like the consensus approach is to add a special code for titles that are not language-specific. The MARC code "zxx" ("no linguistic content") should do the trick, although we may want to change the display value to something like "n/a" for simplicity's sake. It will be easy to change all COVERART records so that their language code would be "zxx".

Now, let's discuss the desired software behavior. Currently, when a new pub is entered, all of its constituent titles are assigned the same language code as specified by the editor in the data entry form. We can change the software so that COVERART records would be assigned "zxx" instead. What about INTERIORART records, though? If we make them default to "zxx", then the editor will have to go back and change the language values for cartoons, maps and other language-specific art. If we make the software use the language specified by the editor, then we'll have the opposite problem. Either way, some post-approval changes may be needed. Ahasuerus 02:30, 26 April 2014 (UTC)

I know we've avoided this sort of thing in the past, but one option would be that when someone makes a submission that contains interior art records, that we take them to another page and ask them more questions: i.e. whether all of those interior art records should be left as "n/a", or if any of them should be changed to the language of the containing title. Chavey 04:10, 26 April 2014 (UTC)
It's possible, but I think it will be much easier to tweak the language assignment algorithm to check for words like "(map)" and "diagram" in the titles of INTERIORART records and use their presence/absence to determine whether to use the specified language code or "zxx". Ahasuerus 23:03, 26 April 2014 (UTC)

Title Editor and Author Editor. I think we can keep them as is. Editors will need to be told to keep "n/a" (or whatever we end up calling it) when editing COVEART titles. Also, they will need to know to select "n/a" when editing artists' author records -- unless the artist was primarily a cartoonist, in which case they will need to choose the language of his cartoons.

Summary Bibliography pages. I don't think anything will need to be changed, although an artist who has done a significant number of covers as well as cartoons may end up with a peculiar looking page. I think the variant/translation logic won't be affected, but I'll need to run more tests.

Title page. No changes that I can think of.

Duplicate Finder. Will probably need to be tweaked to handle "zxx" records as likely duplicates of other, language-enabled records.

Overall, it doesn't seem to be too bad, although chances are that I will discover something else when I start working on it. Am I missing anything obvious? Ahasuerus 02:30, 26 April 2014 (UTC)

Database maintenance

I will be taking the database down for maintenance at 1:35pm server time. I expect it to be back up within 20-30 minutes. Ahasuerus 18:28, 23 April 2014 (UTC)

We are back up. Thank you for your patience! Ahasuerus 18:50, 23 April 2014 (UTC)

Improper use of HTML in title fields

Knowing the use of HTML in a title field is contrary to current standards, about a year ago I went through the database and removed all such uses in the database. I just checked and, since my last check, more than a hundred more titles that contain HTML have been added to the database. In some cases, it is necessary to indicate strikethroughs and superscripts, and that's understandable. Most of them are used to indicate italics in titles. The pertinent standard is indicated in the "Font" subsection of this help page where it states "do not use embedded HTML to show font changes." Mhhutchins 01:26, 30 April 2014 (UTC)