ISFDB:Community Portal/Archive/Archive35

From ISFDB
< ISFDB:Community Portal‎ | Archive
Revision as of 11:34, 12 July 2015 by Nihonjoe (talk | contribs) (header)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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

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

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


Archives of the community portal for January - March 2015

Access Issues

Folks on the FictionMags list are having problems accessing our site. I am also seeing DNS errors here at work and was seeing the same thing yesterday at home, which eventually righted itself. Oddly, I'm having no issues with my mobile device which is how I'm able to post this and why I'll be terse. It seems we may have a larger DNS related issue. --Ron ~ RtraceTalk 19:45, 2 January 2015 (UTC)

I confirm that it's quite erratic (yesterday at this time it was particularly bad). Hauck 19:50, 2 January 2015 (UTC)
Darrah reported a similar problem yesterday, but everything went back to normal when he switched to another PC. Let me check a few things... Ahasuerus 20:24, 2 January 2015 (UTC)
It's been down for me this evening. Whois reports that the name servers are ns1.fhdomains.com, ns2.fhdomains.com, ns3.fhdomains.com, ns4.fhdomains.com, and ns5.fhdomains.com. All five name of those addresses point to 69.64.147.243 which is a bad practice. That name server is down.
I'm assuming those that see isfdb.org as up are using a cached DNS record. A little Google hunting finds the web server is at 208.100.59.10. I added two lines to my etc/hosts file and can get on the site.
208.100.59.10 isfdb.org
208.100.59.10 www.isfdb.org
--Marc Kupper|talk 07:36, 3 January 2015 (UTC)
Still having occasional trouble accessing, a few times a day. Linguist 14:50, 3 January 2015 (UTC).
I've not been able to access at all in the past two days. Only learned how to change my etc/hosts file (thanks, Mark!) and am now aboard. That's not going to help the average user. There's an underlying problem that should be fixed (or probably never should have happened.) Mhhutchins 15:54, 3 January 2015 (UTC)
The company hosting the ISFDB database has been having DNS problems since 2015-01-01. This is making the ISFDB server sporadically/permanently inaccessible to some users. We are currently trying to get them to fix the issue, but we have little control over it short of moving to another provider :( Ahasuerus 17:31, 3 January 2015 (UTC)
Al believes that he has identified the problem with the ISP's setup and has forwarded the details to the ISP staff. Hopefully they will address the issue quickly. Ahasuerus 18:51, 3 January 2015 (UTC)
I wasn't able to access the site at all since the problem started, except when I used Marc's workaround. But it started working again a few minutes ago without the workaround. The whois record for isfdb.org shows an "Updated Date: 2015-01-03T18:49:20Z", so maybe something was fixed and the DNS record updated. Jens Hitspacebar 19:00, 3 January 2015 (UTC)
Yes, I was just about to post that the DNS settings were adjusted a few minutes ago and things are looking up -- Google's DNS servers and other sites can see ISFDB now. There are a few sites that still can't see us, but it's just a matter of time until the new information is propagated everywhere. Ahasuerus 19:01, 3 January 2015 (UTC)

The Night Cache

Anybody know why Andy Duncan's The Night Cache is tagged as non-genre? I'm surprised given it is a World Fantasy nominee and was contained in The Best Science Fiction and Fantasy of the Year Volume Four (my version of that pub is unfortunately not easily accessible). I tried looking through recent changes for an edit that set the flag but I either missed it or it's further back than I have the patience to look. So I thought I'd make a general inquiry here. Thanks. -- JLaTondre (talk) 17:45, 4 January 2015 (UTC)

It was changed by Pete Young on December 22, the day the function was implemented. (I had to search back through more than 50 pages of submissions to find it.) I've not read the story, but I have primary verified four of the five publications in which the story appears. It would seem proper ISFDB etiquette to notify primary verifiers before making such a change. (So far, I've rejected two submissions that tried to do the same thing without discussing it with the PV editor.) I'll ask Pete to join the discussion. Thanks for bringing this to the group's attention. We need to start a larger discussion about changing the genre status of titles which appear in primary verified records. Mhhutchins 18:53, 4 January 2015 (UTC)
According to one review, the story is "about lesbian love, cryptography, and signals from beyond the grave". Another calls it a "nice cerebral ghost story with a cool ending." Sounds genre enough for me. Mhhutchins 19:01, 4 January 2015 (UTC)
Let me just chime in to add that the moderator review page for "Edit Title" was modified a couple of months ago to show all pubs associated with the about-to-be-changed title. Ahasuerus 19:13, 4 January 2015 (UTC)
Yes, that was a wonderful feature. So now a moderator doesn't have to do anything to see that a title appears in a PV'ed publication. Mhhutchins 19:33, 4 January 2015 (UTC)
The review Michael quotes is actually a bit of an oversell by the reviewer: there are no ghosts, just a geocached message left for a friend from someone who had died. While it's a light mystery story that might appeal to genre fans (hence its inclusion in a genre anthology) there are actually no spec-fic elements to the story. (I read it in the PS Publishing hc chapterbook which I verified on 31 May 2014). I agree we will need to start a discussion on the genre/non-genre status of short fiction when it appears anthologised and PVed by editors other than oneself. Please put down my not initiating such a discussion over this title wherever it appeared as an oversight – I think we're all still getting a handle on the non-genre support and all the inherent circumstantial details. PeteYoung 22:46, 4 January 2015 (UTC)
It was published by a spec-fic specialty publisher, it was reviewed in the major spec-fic reviewzine, it was reprinted in a best of the year anthology for fantasy and horror, and it was nominated for a major fantasy award. Even if it were the author's grocery shopping list, it should be considered spec-fic. Mhhutchins 01:04, 5 January 2015 (UTC)
Well, the story is "above the threshold", so I am sure we want to include it, but if there are no speculative elements, is it really speculative fiction? I suppose this is one of those very rare "corner" cases where everyone within the genre seems to say "yes, this is SF", but there is no actual speculative content... Ahasuerus 01:48, 5 January 2015 (UTC)
P.S. I should add that typically I don't spend too much time worrying about corner cases. They are by definition rare and unpredictable, so they are best handled via Notes. Ahasuerus 01:55, 5 January 2015 (UTC)
Well Michael, forgive me for attempting to be concise in what is and is not non-genre, and focussing on the story itself rather than the surrounding activity it engendered: anthologised, reviewed, nominated, all of which ought to be secondary considerations when determining if a story is itself genre or otherwise. Spec-fic grocery shopping lists included, we aim for accuracy here. As I understand our definition of non-genre, if the story contains no speculative elements, it is a non-genre story. I respectfully ask that you please illuminate me if this is an incorrect assessment. PeteYoung 06:09, 5 January 2015 (UTC)
If there is one thing that I have learned while working on ISFDB -- and BTW, we turn 20 this year! -- it's that no matter how blindingly obvious something is (to me, that is), there will always be another contributor who will have a totally different take on it :) Ahasuerus 06:19, 5 January 2015 (UTC)
After reading the story itself, it seems to me that the fantasy elements could be rationally explained, or a reader could just as easily accept them as fantastical, something that the author clearly wants them to do. It's always been an ISFDB standard in borderline cases to err on the side of inclusion. I've removed the non-genre designation from the story. Mhhutchins 08:15, 26 January 2015 (UTC)

James White's The Exorcists of IF

This item appears to be rather a piece of shortfiction than an essay, though the personnel is taken from the Irish Fandom. If there's no objection, I will change the title to a short story. Stonecreek 16:47, 5 January 2015 (UTC)

Agreed. It's an essay, but presented as a short story. Bob 17:06, 5 January 2015 (UTC)
OK for me. Hauck 17:39, 5 January 2015 (UTC)
Okay for me, also.SFJuggler 05:55, 11 January 2015 (UTC)

CHAPTERBOOK replacement -- final call

As discussed above, we need to replace the term "Chapterbook" with a different, less inaccurate term. At this time the leading candidates are "Chapbook" and "Booklet". Please post you choice below. Ahasuerus 02:55, 7 January 2015 (UTC)

1 - CHAPBOOK Mhhutchins 04:20, 7 January 2015 (UTC)
2 - CHAPBOOK Stonecreek 04:30, 7 January 2015 (UTC)
3 - CHAPBOOK Kraang 04:39, 7 January 2015 (UTC)
4 - CHAPBOOK RR 05:51, 7 January 2015 (UTC)
5 - BOOKLET Linguist 10:06, 7 January 2015 (UTC).
6 - CHAPBOOK PeteYoung 10:49, 7 January 2015 (UTC)
7 - CHAPBOOK MartyD 11:29, 7 January 2015 (UTC)
8 - CHAPBOOK Rtrace 13:29, 7 January 2015 (UTC)
9 - BOOKLET Hauck 15:16, 7 January 2015 (UTC)
10 - CHAPBOOK Albinoflea 19:01, 7 January 2015 (UTC)
11 - BOOKLET Rudam 19:19, 7 January 2015 (UTC)
12 - CHAPBOOK --Willem 19:28, 7 January 2015 (UTC)
13 - CHAPBOOK --Chris J 21:36, 7 January 2015 (UTC)
14 - BOOKLET Patrick -- Herzbube Talk 21:45, 7 January 2015 (UTC)
15 - BOOKLET Chavey 00:45, 8 January 2015 (UTC)
16 - CHAPBOOK Ahasuerus 03:56, 8 January 2015 (UTC)

Tally: 11 CHAPBOOKS, 5 BOOKLETS. Thanks to everyone who voted! I will change CHAPTERBOOKS to CHAPBOOKS once I finish fixing "combining diacritics". Ahasuerus 17:16, 10 January 2015 (UTC)

Performance problems -- 2015-01-07

I am aware of the sporadic performance problems that we have been experiencing for the last 24+ hours, but I haven't been able to identify the root cause of the problem. I suspect that the problem is with the underlying server, which, unfortunately, is not something that I have control over. Ahasuerus 06:11, 7 January 2015 (UTC)

Performance? I got errors connecting to the DB a few times (I think it was last week; the message was from the Python so DNS was working for me then). Uzume 02:13, 8 January 2015 (UTC)
Database connection errors usually happen around 9:30am server (US Central) time while the backups are running. Ahasuerus 03:37, 8 January 2015 (UTC)

US publisher Pocket = Pocket Books

There are a couple dozen verified records which give the publisher as "Pocket", which can possibly be confused with the French publisher of the same name. So the overwhelming majority of books from the US publisher are given as Pocket Books, while those from the French publisher are entered as Presses Pocket. If you have verified records for books from the US publisher as just Pocket, please consider changing them to "Pocket Books" (the actual name of the publisher given on their title pages.) Thanks. Mhhutchins 06:58, 9 January 2015 (UTC)

Combining Diacritics

I have been working on Bug 423 for the last few days and I expect to release a patch in the next 24-48 hours. There will be some manual cleanup required after the patch, so let me first explain what's going on.

There are 26 core characters like "a" and "z" shared by most Latin-based alphabets. In addition, there are many other Latin-based characters like é or ȟ used by some (but not all) alphabets. The most common standard for storing and transmitting these (and many many other) characters is called Unicode. ISFDB uses Unicode as well, although with some caveats, which we don't need to go into here.

For better or for worse, Unicode is a rather flexible standard and lets you do certain things in more than one way. One example of this flexibility is what is known as "combining diacritics". What this means is that you can enter the letter ȟ in two ways: either as "ȟ" or as "ȟ".

At this point you are probably looking at my example and thinking "Wait, but isn't it the same character?" Unfortunately, the answer is "no". If you edit this section of the Community Portal, you will see that the codes that are used to represent these two occurrences of "ȟ" are different. The first occurrence is actually "&#" followed by "543" and a semicolon, which is one way to display this Unicode character in HTML. The second occurrence consists of the letter "h", "&#", "780" and a semicolon, which tells the browser to display "h" combined with the "combining diacritic" represented by "780". In this case the combining diacritic is a "caron" or an "inverted circumflex". There are over a hundred "combining diacritics" supported by Unicode and if you multiply it by 26, you can see that there are more than 2600 possible permutations for Latin characters alone.

In a way, this Unicode feature is nice because it lets you create characters that do not exist in any language, e.g. "Z̮". On the other hand, it also lets you enter the same character in two different ways: as a regular Unicode character and as a character followed by a combining diacritic. This can cause data duplication, e.g. we have André Maurois and André Maurois. It also messes up searches for obvious reasons. Since some bibliographic Web sites, including WordCat, use combining diacritics and since some editors use copy-and-paste to get data into ISFDB, it's a bigger problem that I originally realized.

Here is how we are going to address it. The data entry logic will be modified to convert all "recognized" combinations which contain combining diacritics to their Unicode equivalent. The change has already been made on the development server and seems to be working fine. In addition, all title and publication records in the database will be automatically converted from combining diacritics to their respective Unicode equivalents.

However, please note that I will not be auto-converting author, series, publisher or publication series records. In certain cases it could cause record duplication, which is either not allowed by the software (authors, series) or is not allowed as a matter of policy (publishers, publication series). I will post a list of affected records on the Moderator Noticeboard and moderators will be able to fix them manually. It's not a huge amount of work, only a couple hundred records when you add up all record types. Ahasuerus 02:51, 11 January 2015 (UTC)

"ȟ" and "ȟ" are displayed differently on my computer. The first has a diacritical mark above it, the second displays a square box on top of the closing quotation mark. In any case, I understand your explanation of the two options a user has to create characters with diacritics, and the necessity to make one the ISFDB standard. I'll help in the process to convert those records that can not be done automatically. Thanks. Mhhutchins 08:15, 11 January 2015 (UTC)
Yes, it's up to each individual font to decide how to display characters with combining diacritics. Some fonts are only designed to handle a limited subset of possible permutations, which, in this case, is arguably an advantage :) Ahasuerus 15:00, 11 January 2015 (UTC)
Ok, all understood (I hope). Let's take it on. Stonecreek 17:10, 11 January 2015 (UTC)

(unindent) The data entry logic has been changed to convert known permutations to their standard values. All affected title/publication records have been auto-converted. I am currently working on 4 cleanup reports to facilitate fixing author, series, publisher and pub series records.

P.S. While working on this bug, I found a few other Unicode characters that need to be changed by the data entry logic. I will fix them in a later patch. Ahasuerus 05:43, 12 January 2015 (UTC)

Hello. Would this new patch have an incidence on this ? I have just recorded a new pub in the “Bibliothèque de la Pléiade” series, which has produced a duplicate on the Gallimard Publisher Record. I suspect the grave and acute accents of being the culprits… Linguist 16:04, 13 January 2015 (UTC).
Yes. A new cleanup report should find this culprit. We just finished fixing 86 publishers with bad characters. I suppose the report for publication series will be coming soon. Thanks. Mhhutchins 17:55, 13 January 2015 (UTC)
I went ahead and fixed this publication series. You can actually do it yourself. Just remember that just replacing the combined diacritics won't work. In the submission to change the character to a non-combined one, add a differentiating character (such as "1") at the end. Otherwise the system won't recognize the change of a combined character with a non-combined character. You then have to go back and remove the "1". Hope this makes sense. Mhhutchins 18:05, 13 January 2015 (UTC)
OK, thanks. I sort of understand the general idea. Looking forward to falling upon a similar problem to try my hand at it… Linguist 22:11, 13 January 2015 (UTC).

Proposed changes to the New Publication data entry form

As per discussion above, the following suggestions re: the "New Publication" data entry form have been made:

  1. Move the "Title Data" section, which currently includes "Language", "Series", "Series Num", "Non-Genre", "Synopsis" and "Web Page 1" through "Web Page N", to the top of the page.
  2. Change the name of the "Pub Type" field to "Title Type" and move it from the "Publication Metadata" section to the "Title Data" section, next to the "Non-Genre" field.
  3. Change the "Non-Genre" field to a check-box.
  4. Add "Non-genre" check-boxes to each titles-specific area of the "Content" section.

Personally I like changes 1-2 and I am neutral on 3, but I don't think that 4 would be justified in terms of the extra real estate/UI complexity that it would require. Ahasuerus 15:30, 12 January 2015 (UTC)

I would very much like to see 1 and 2 implemented, not sure if there's an advantage one way or the other about 3, and understand that 4 would be very difficult to implement, and not worth the effort to do so. Thanks. Mhhutchins 19:51, 12 January 2015 (UTC)
Are there any objections to 1 and 2? If not, I can do it tomorrow. Ahasuerus 05:16, 14 January 2015 (UTC)
No objections from here. Stonecreek 07:36, 14 January 2015 (UTC)
Done. How does it look? Ahasuerus 23:28, 14 January 2015 (UTC)
It may take me a while to get used to it, but it doesn't look like it will be too long. I have one concern. When someone is adding a new publication for a title not in the database (i.e. using the "Add New..." function"), do you think there could be a problem with the Year field (which I've always felt should be called the Date field). They might assume it means the date of the title (since this is the title data they're entering) and not the date of the publication. So they could enter a date different from the publication. That was never a problem when the "year" field was part of the publication metadata section. Maybe I'm just being too picky, but I can see the possibility. What do others of you think? Mhhutchins 23:38, 14 January 2015 (UTC)
Well, it's a valid point, but I am not sure what we could do about it. Perhaps move the "Year" field to the "Publication Data" section? And yes, I agree that we need to standardize the name of the field -- in some cases we use "Year" while in other cases we use "Date". FR 765 created. Ahasuerus 15:59, 15 January 2015 (UTC)
Looks great! It whets my appetite even more than before! Stonecreek 15:46, 15 January 2015 (UTC)
Thinking of it, a mess-up like this could indeed happen. Stonecreek 16:27, 15 January 2015 (UTC)

PubType in NewPub made non-editable

As per FR 760 and this discussion above, "Publication Type" has been converted from a drop-down list to a non-editable field. This change applies to the New Publication data entry form only. Ahasuerus 05:09, 14 January 2015 (UTC)

Unicode spaces

Now that we have taken care of combining diacritics, let's review "Unicode spaces". There are at least 20 Unicode characters that are used to represent different types of spaces: "en space", "em space", "figure space", "thin space", "hair space" and so on (see this page for a full list.) Of course, storing them in the database presents the same problems that using combining diacritics does -- failed searches and increased chances of data duplication.

It looks like all of these "Unicode spaces" could be safely auto-converted to regular spaces at data entry time except for the following oddball characters:

  • OGHAM SPACE MARK - "usually not really a space but a dash"
  • ZERO WIDTH NO-BREAK SPACE - "No width (the character is invisible)"

Do we have anyone on board who would know how these characters are used and whether it would be safe to auto-convert them to dashes and "no character" respectively? Ahasuerus 00:06, 15 January 2015 (UTC)

It's not likely that they would ever actually be used in the title of a publication or an author's name, so what's the point in trying to keep them in the database? I say auto-convert them and be done with it. Mhhutchins 00:42, 15 January 2015 (UTC)
Ogham is an ancient Irish Celtic language. The combined total of all of WorldCat appears to contain three books written partially or in full in Ogham, and only one in which the title is in Ogham. I think it's safe to do whatever you want with it. (A dash seems fine, although transliterations appear to use a space.) Since we don't do word breaking anywhere, the purpose of a zero width non-breaking space is irrelevant to us, so I think we can safely convert to a "no character". Chavey 07:15, 15 January 2015 (UTC)
Thanks! The changes have been coded and I am currently in the process of testing them. Ahasuerus 15:27, 15 January 2015 (UTC)
The patch has been deployed. All Unicode spaces, apostrophes and double quotes are now converted to their regular equivalents at data entry time. Two new cleanup reports have been added: "Titles with Invalid Unicode Characters" and "Publications with Invalid Unicode Characters". There are 66 affected records, so it's not too bad. They can be fixed by using the same technique as the one we used earlier.
In addition, I have identified and manually adjusted about a dozen title records that use ʻ and ʼ incorrectly. They are apparently valid characters in certain Asian languages, e.g. see this title, so we can't auto-convert them, but we shouldn't be using them as a substitute for apostrophes. I may need to create a separate set of cleanup reports that would find these characters and then allow moderators to "ignore" valid records. Ahasuerus 17:58, 15 January 2015 (UTC)
Can we auto-remove all of those leading spaces in Italian titles? It's kind of disconcerting when doing a search to see them listed at the top of an otherwise alphabetized list. (Do an advanced search for "complete novel" to see my point.) Mhhutchins 20:01, 15 January 2015 (UTC)
Oh. The data entry logic strips all leading and trailing spaces, but I guess these records were created before it was implemented. Sure, let me write a conversion script... Ahasuerus 20:54, 15 January 2015 (UTC)
Fixed. Ahasuerus 23:34, 15 January 2015 (UTC)

"Forthcoming" dates?

There are 22 "Forthcoming" (aka "9999-00-00") publications and 12 "Forthcoming" titles in the database. You can find them by using Advanced Search and specifying "9999" as the Title/Publication year. In many cases these records appear to be vaporware, e.g. Seek a Newer World or this pub record, which is described as "Scheduled for 2010-11-01, but apparently never published.", and should be changed to 8888-00-00.

Should we simply disallow 9999-00-00? Or am I missing one or more valid scenarios that would justify keeping it? Ahasuerus 18:17, 15 January 2015 (UTC)

No, I can see a valid reason for keeping it and actually using it. For example: a work is scheduled to be published later in 2015 but with no set date. An editor would enter 2015-00-00 and it would appear to have already been published. Using 9999-00-00 makes it clear that the book hasn't been published. I know we have an unstated policy (I think it's unstated) that publication records shouldn't be created for works scheduled for publication more than three months away. But I've seen editors add records for works further out than that, so I update the record's date to 9999 and give the scheduled date in the Note field. I believe more moderators and editors should be using 9999 in such situations. Mhhutchins 20:08, 15 January 2015 (UTC)
With that in mind, I believe we should also follow-up to correct the dates once the book has been published or to change them to 8888 if the titles were cancelled. If we choose to keep 9999, I will accept the task of maintaining those records. Mhhutchins 20:16, 15 January 2015 (UTC)
OK, I can see how it could be workable. However, if we are going to rely on a periodically occurring manual review process, I think we need a couple of reports to support it. <fx: sounds of furious typing> We have two new cleanup reports, "Forthcoming (9999-00-00) Publications" and "Forthcoming (9999-00-00) Titles". The software has been deployed, but the reports won't be run until the next iteration of the nightly job. Ahasuerus 00:36, 16 January 2015 (UTC)
Is it possible to add a note explaining that these are not exactly errors? Moderators should only check to see if the book has actually appeared, not necessarily "clean" it. Mhhutchins 07:38, 16 January 2015 (UTC)
That's a good point. I have created a new section on the "ISFDB Data Cleanup Reports" page and added a note to the "Forthcoming" reports. Ahasuerus 01:18, 17 January 2015 (UTC)
I understand it would likely take more work than Ahasuerus' recent sound effects (i.e., the new cleanup reports) but methinks if such a concept is useful it would be even more useful as a separate bit in the DB records of those record types. With such a feature in place one would very easily query which "forthcoming" records are obviously no longer forthcoming (marked forthcoming but which are obviously no longer in the future). Turning them to 9999 and putting comments in the records makes any ability to machine read the date in the comment extremely hard (making for a manual process to review all 9999 records periodically). I am not a fan of processes that are designed unsustainably. I can foresee a future where the sheer number of publications (likely ebooks) could outstrip even Michael's ability to keep up with forthcoming records even if we restricted them all to being within the currently unstated three month future. Uzume 08:46, 16 January 2015 (UTC)
As an addendum to that, we could easily turn the forthcoming bit on by default whenever someone enters a future date (that is not one of the special dates) at submission and/or moderation time. Uzume 08:58, 16 January 2015 (UTC)
If records are within the three-month period, they are dated the announced date of publication and not 9999. Only those beyond the three-month period or are unpublished more than a year past their original announced dates have been changed to 9999. (The latter group will eventually be changed to 8888.) There is a relatively miniscule number of records in the database which are dated 9999 (currently, 7 pubs). Do an advanced search (as I suggested) and you'll see. They can be easily handled by a moderator. I don't foresee there ever being more than a couple dozen in the database, because they have to be changed to 9999 manually. The system never dates a record as 9999, even though they are displayed along with all titles that have a stated publication date beyond today as "forthcoming". A question to moderators: how many of you actually use this feature (changing the date of a publication to 9999)? Mhhutchins 18:33, 16 January 2015 (UTC)
I agree that the current number of "Forthcoming", i.e. 9999-00-00, records is eminently manageable. On the other hand, I think Uzume's larger point is also valid. The risk of entering bibliographic data for books that are yet to be published is significantly higher than for books that have already appeared, complicated corner cases like this one notwithstanding. It would be nice to be able to go back and double check our pre-publication records created by Fixer (and Dissembler), but there is nothing in the software to support this functionality at this point.
Thinking about it, I guess there is one thing that we could do. When Fixer creates a record, he leaves a note which always uses the same format, "Data from [source] as of 2014-11-21". (Of course, the text is supposed to be changed when the book is primary-verified.) We could create a cleanup report that would look for books whose publication date is in the past, e.g. Today-60 days or even Today-365 days, but whose Note field still says that the record was created before the cook was published. A reviewer could then double-check that the book was published on schedule and adjust publication data if needed.
This kind of report wouldn't be that hard to code, but checking previously-entered-but-never-verified data could be potentially very time-consuming... Ahasuerus 01:42, 17 January 2015 (UTC)

Thomas De Quincey

Hello. Following this brief exchange, and a related held submission, does anyone care to express an opinion about whether or not Thomas De Quincey's Confessions… should find a virtual resting place in this database, considering that an excerpt of the aforesaid work already exists here ? TIA, Linguist 21:15, 16 January 2015 (UTC).

The anthology which reprints the excerpt may have selected a small section of the work as having fantastic elements. That doesn't make the whole work eligible for the database. Perhaps that's why it's labeled fiction when the whole work is nonfiction. Mhhutchins 21:36, 16 January 2015 (UTC)
I haven't read the book, but it's my understanding that it's an autobiographical account of an opium addict and contains vivid descriptions of his experiences. I guess certain hallucinatory episodes could be considered speculative fiction (especially considering that we try to be inclusive when dealing with older works), but the book itself may not be. Ahasuerus 01:46, 17 January 2015 (UTC)
OK. As Ginger said to Fred (or the contrary), let's call the whole thing off… Linguist 09:46, 18 January 2015 (UTC).
As a general observation, dreams can be tricky. In some cases they are integral to the story, e.g. in F. Anstey 's Tourmalin's Time Cheques, while in other cases only the dream sequence is SF, e.g. Nikolai Chernyshevski's "Vera Pavlovna's Fourth Dream". Ahasuerus 19:28, 18 January 2015 (UTC)

Linking to FictionMags

As some of you know, FictionMag has the same problem that the Locus Index has, i.e. their URLs change with every update, so it would be pointless to link to them.

However, Bill Contento, who works on the FictionMag Index, has pointed out that there is another, more stable, way to link to FictionMags. Let's use "Black : Australian Dark Culture Magazine" (http://www.isfdb.org/cgi-bin/pe.cgi?37532) as an example. Its regular FictionMag URL is http://www.philsp.com/homeville/FMI/b36.htm#A600 this month, but it will be something else after the next update, so we can't link to it. The stable URL that we want to use instead is http://www.philsp.com/homeville/FMI/link.asp?magid=BLADC , which always automatically redirects to the current (unstable) URL. I have changed our Series link to http://www.philsp.com/homeville/FMI/link.asp?magid=BLADC and now the linkage is working again. These stable URLs are available from the "All Magazines" index (http://www.philsp.com/lists/a_mag01.html), you just have to use the link in the "Indexed In" column when it says "FicMags". Ahasuerus 02:38, 18 January 2015 (UTC)

That is an interesting find. In a similar way one can link the data page (outside FMI) as well: http://www.philsp.com/links2.asp?magid=BLACKAUSTRALIANDARKCULTURE Apparently this works for even for magazines not indexed by FMI such as: http://www.philsp.com/links2.asp?magid=ABORIGINALSCIENCEFICTION Uzume 16:18, 21 January 2015 (UTC)
Those links are to the periodicals' listings on Galactic Central website, which provides even more data about the periodicals (though not the contents). So linking to both FictionMags, when available, and to GC would be a good idea. Thanks. Mhhutchins 16:31, 21 January 2015 (UTC)

Philip K. Dick fans / bibliographers?

If you are a bibliographer who works on Philip K. Dick, or a fan, there is a major PKD auction going on right now on eBay. This seller has 594 books for sale, all but one either by or about PKD. (Plus 95 magazines, most of which probably have PKD articles or stories.) So if you wanted to check if our bibliography page is missing something (or your collection is), this might be a good opportunity. Chavey 03:12, 20 January 2015 (UTC)

The images are worth grabbing, but less than a handful of the book editions are in English. An impressive display, nonetheless!! --~ Bill, Bluesman 01:32, 21 January 2015 (UTC)
Interesting find—too bad it is being split up/sold off as I assume someone had to have put much time into such a collection. I noticed some items are so cheap too: http://www.ebay.com/itm/111577795279 Uzume 03:51, 24 January 2015 (UTC)
Thanks for the link, I'll look through the items! Stonecreek 04:18, 24 January 2015 (UTC)

Dealing with broken links for author webpages

The webpages we have for authors fairly regularly contain broken links. I was surprisingly effective (IMHO) at correcting one of those today using the following algorithm: I went to the Wayback Machine (easily found by Googling that phrase) and entered the broken link. It didn't actually have a history of that link, but I went to its parent directory, and it had that. That page had prominently displayed the title "Nevada Writers Hall of Fame", so I Googled that, found the new location for the author bio, and updated our record. All in about 3 minutes. I recommend this tactic to others.

While I'm at it, this might be a useful "Cleanup Script" to run occasionally: Find all such broken links and give us a list of them so we can try to repair them. Chavey 02:40, 22 January 2015 (UTC)

There is a cleanup report that lists Publications with Suspect Images. There is a Feature request to expand the report to check all types of URLs. Ahasuerus 03:13, 22 January 2015 (UTC)
Ah, good. Chavey 04:23, 22 January 2015 (UTC)

Capturing romanized and translated versions of records

We have an FR that asks to:

  • Add a field for romanized/transliterated form of each title record. It will be used when the original title uses a non-Latin alphabet.

It's a good idea, but I think it needs to be fleshed out. First of all, we will need to enhance the search logic to use this field in addition to the main title field when performing searches. That way our users will be able to search either for the original Japanese/Cyrillic/etc title or for the romanized form of the title and still get the same result.

Second, we need to add similar romanized fields to the following record types:

  • publication
  • publisher
  • publication series
  • author

Naturally, the search logic will have to be adjusted accordingly. Not only will it make the software behave consistently across the board, but in the case of author records it will also enable us to start using the original form of author names without affecting current search behavior.

Third, we may want to make these romanized names/titles available on bibliography pages as mouse-over text, which seems like a reasonable compromise: the data will be available if needed without making pages too busy.

Fourth, we may want to add another field, "[literal] English translation", to the following record types:

  • title
  • publication
  • publication series
  • publisher

Not only will it help with untranslated works, but it will also help with works that have been translated into English. Publishers love to pick new titles for translated books, e.g. back in the 1970s Pierre Barbet's "L'empire du Baphomet" became "Baphomet's Meteor" and "Les grognards d'Éridan" became "The Napoleons of Eridanus", so a literal translation of the original title can be valuable.

Fifth, we can make the data entry software smart enough to populate the romanized field(s) automatically if they are left blank. It may not be perfect, but it will create a temporary value until a more language-savvy editor comes along. (Or does this create potential for shoddy data getting into the database?)

Does this seem like a reasonable direction to take? If it does, then we can discuss additional implementation details.

For example, should we also use the "romanized" field to record simplified, English/ASCII-characters-only forms of names/titles that use Latin-based alphabets? Consider Kurt Mahr's Das strahlende Gefängnis. The way the software works at this time, if an English-only user enters "Das strahlende Gefangnis" (note the last "a") in the search box, the search will fail. If, however, we implement the proposals outlined above and enter "Das strahlende Gefangnis" in the new "romanized title" field, subsequent searches will be successful. Ahasuerus 06:20, 25 January 2015 (UTC)

IMHO, we should stop at step 3. I don't see any value in the next ones apart for lots of headaches => as per your example, "grognards" is a typical french military term that can be translated variously (grunts, veterans, soldiers, elite troopers, etc.), or just a waste of disk space for some of the fields (should a publisher like "Robert Laffont" be translated? By what, "Bob The Bottom"?). Hauck 11:10, 25 January 2015 (UTC)
“Bob Well” would be more to the point ! :oD (from Old French fons, font “well, spring”, a feminine noun). Linguist 22:15, 25 January 2015 (UTC).
I was thinking about more descriptive publisher names like Detske Knihy ("Children's Books" in Czech), Detskaya Literatura ("Children's Literature" in Russian) or even Presses de L'Université du Quebec, but I agree that it's relatively rare. The functionality would be more useful when dealing with other record types, e.g. it's nice to be able to tell that Библиотека приключений и научной фантастики means "Library of adventure and science fiction". Ahasuerus 18:16, 25 January 2015 (UTC)
Your point is interesting in the sense that there are entries in the ISFDB that are simply not understandable by me (I can only stare at this record). Your romanization is indeed a way to solve this but I'm afraid of the potential cost (at all levels: disk space, contributor's time, frictions between persons who have different ideas of the "right" romanization as we're a bunch of highly opinionated and vociferous people) that it can entail. Hauck 18:30, 25 January 2015 (UTC)
As far as titles go, I agree that multiple translations are often possible, but I was trying to think of a way to capture the data that our editors are already entering in a more structured way. For example, Linguist has been adding English translations of Russian titles for the last few months -- see the Note field in "Вечер накануне Ивана Купала", "Страшная месть" or "Выстрел". Ahasuerus 18:33, 25 January 2015 (UTC)
This is not a bad idea but I have a few issues with these concepts in general. There seem to be two main issues: add romanized fields and add literal English translation fields. Both of these effectively double the number of title fields that need to be maintained and we have no rules about how either of these need to be handled. The literal English translation fields would be hard to make rules for (how do your standardize translation even in a more literal form whatever that means) and it (of course) is very English concentric, favoring one language over many others. For these reasons, I, like Hauck, believe the literal English translation fields have little return on investment (ROI) and am thus against them (although well intentioned; and I am an native English speaker). The other thing to consider is if you are interested in transliteration or transcription. Romanization can be very different depending on which you are interested in.
As for the romanized fields, in speaking from my experience with Japanese, we would have to have rules on this to make it effectively useful. For Japanese alone, there are several possible "standardized" romanization methodologies including: Hepburn, Kunrei-shiki, Nihon-shiki, JSL, and even Wāpuro. Among those Hepburn is favored by English speakers (more transcription) and Kunrei-shiki is most standardized (as an ISO standard and favored by Japanese government because it is more transliteration). In terms of the original fifth point, both hiragana and katakana could be machine romanized easily but due to complications in pronunciations for kanji (e.g., on'yomi and kun'yomi, to say nothing of dialects and old Japanese), it cannot be machine romanized well without complex dictionary software (which are actually somewhat common for contemporary Japaneses information processing input methods but how complex do we want the ISFDB software to be? and this is only one language).
If we are considering romanization do we want to consider other transliterations (or transriptions) such as cyrillization? For Japanese at least there are things like cyrillization of Japanese
I am unfamiliar with transliterations and transriptions for other languages. For Chinese, I image there would be a vast array of methods not to mention the complications of many pronunciations in the all the many dialects considered "Chinese" (even outside of transliteration there are many Chinese writing system variations, the largest and most common being traditional vs. simplified). Uzume 13:44, 25 January 2015 (UTC)
As far as Chinese is concerned, I don't think we have many records in other languages than Mandarin (maybe a few in Cantonese, perhaps, but I haven't seen any go past). And as for Mandarin, the pinyin transcription seems to be the standard one — although it raises a few pronunciation issues for the average western reader; but there again, so do Polish or Latvian ! I had raised this topic earlier, concerning the canonical form that should be given to Chinese authors' names (and in my opinion, they should all be noted in pinyin). Linguist 22:15, 25 January 2015 (UTC).

(unindent) Let me try to address some of the concerns raised above:

  1. Adding new fields for romanized titles would "double the number of title fields that need to be maintained" and incur "potential cost [including] disk space, contributor's time".
    • Adding an additional field to a database table has minimal impact on disk space until you start populating the field. In terms of maintenance, it will be an optional field just like our Note fields. Editors who do not feel like populating this field won't need to do anything. Those who currently add transliterated titles/names to Notes will start using the new field.
  2. Adding literal English translations would be "English concentric, favoring one language over many others".
    • This is true, but then all of our supporting data, i.e. Notes and Synopses, is already in English. The rule of thumb is that we enter actual data "as is" but any data about our data is in English since we had to pick a single language. 700 years ago it would have been Latin, 300 years ago it would have been French and 100 years from now it may be Chinese or something else, but for now it's English. (The same considerations apply to the issue of "cyrillization" etc.)
  3. "we would have to have rules on this to make it [romanization] effectively useful".
    • Indeed, there are many ways to romanize a title/name. When the question last came up, I listed more than a dozen transliteration schemes used to romanize Cyrillic words. As Uzume and Linguist pointed out, there are similar complications with Japanese, Chinese and probably other alphabets. We will need to pick a single method/scheme and use it consistently or else the whole thing will be pointless. Some SFE3 articles have this problem, e.g. their Shefner article uses two different romanization algorithms.

Let me take a step back and use the SFE3 article linked immediately above as an example. Note how they use romanized forms of Russian titles and provide English translations when there is no known English translation available. The article is not perfect -- in addition to the romanization issue mentioned earlier, the use of English translations is inconsistent, e.g. see "Kovrigin's Chronicles" -- but that's data entry problems rather than a flaw in their methodology. This and other SFE3 articles (like this one) are good examples of the kind of data that we will make available to our users if the proposed approach is adopted. Ahasuerus 02:01, 26 January 2015 (UTC)

I don't really like the idea of a built-in English translation of things like untranslated titles, publisher names, or publication series. It's not the disk space I'm concerned with (I understand enough about SQL databases to know that's trivial), but rather the screen real estate that can easily get too cluttered. Maybe if there were a mouse-over "?" that on clicking gave the Google translation into the user's primary language, then it could be useful without adding GUI clutter. Chavey 07:31, 28 January 2015 (UTC)
Using Google Translate is an interesting idea. The good news is that their API is publicly available. The bad news is that it's a paid service, but the really bad news is that Google Translate is not quite ready for prime time. Here is what it does with some of Shefner's (see above) titles:
  • "Запоздалый стрелок, или Крылья провинциала" ("A Belated Marksman, or A Provincial's Wings") -> "Belated Arrows or Provincial Wings"
  • "Девушка у обрыва, или Записки Ковригина" ("A Girl at the Cliff, or Kovrigin's Chronicles") -> "The Girl at the Cliff, or Notes Kovrigina"
  • "Человек с пятью "не", или Исповедь простодушного" ("A Man with Five "not"s, or Confession of a Guileless Man")-> "A Man with Five "not" or Ingenuous Confession"
As far as screen real estate goes, my thinking was that translations would use the same mouse-over bubble as transliterations. Ahasuerus 00:15, 29 January 2015 (UTC)
I do like the idea of having another field to handle transliterations so that we can keep both original scripts and transliterations. When I filled out the first publications of 80 languages of the Arabian Nights series, I did the opposite of what Linguist has been doing: I put the transliterations in the Title and the original character script in the Notes. It would be nice to have to make either compromise. I think it can be useful to consider WorldCat as a "role model" for handling multiple languages. Their data isn't always as structured as ours, but they're very good at how they handle searches, regardless of the entry format. For example, if I search for Pushkin's "Руслан и Людмила", the transliteration "Ruslan i Liudmila", the alternate transliterations "Ruslan i Lyudmila" or "Ruslan i Ljudmila", or the English translation "Ruslan and Lyudmila", I get the same records. (And I can enter either Das strahlende Gefängnis or Das strahlende Gefangnis.) I'm not sure how they do that, but it's a worthy goal to strive for. And they don't try to standardize transliterations; I suspect different libraries enter their data using whatever their standards are, or were at the time the data was entered. Chavey 07:31, 28 January 2015 (UTC)
I don't know what the OCLC folks do with the bibliographic data that they get from libraries, but that data is mostly structured using one of the MARC standards, typically MARC21. The MARC standards allow multiple titles per publication, including what they describe as "Cover title", "Running title", "Spine title" and so on. Once your software allows multiple titles per book, it's easy to see how transliterated titles could be accommodated. Ahasuerus 00:27, 29 January 2015 (UTC)
I can see us wanting to standardize transliterations, but this leads to challenges when our primary record of an edition is WorldCat -- if that record doesn't use the transliteration scheme we're using, then we might not be able to enter any transliteration. Chavey 07:31, 28 January 2015 (UTC)
I have been thinking about the "automated romanization" scheme that I mentioned earlier. If we can agree on a deterministic romanization algorithm, i.e. a set of rules which, given arbitrary input, will always result in the same romanized output, then we won't need an additional human-editable field. The romanized form of the title/name will be automatically created at data entry time and will be automatically changed if and when the title/name is changed.
Unfortunately, it's not clear whether a deterministic algorithm is feasible in this case, e.g. consider Unicode Transliteration Guidelines which are quite complex and allow for different implementations. Even if an algorithm is deterministic, it may be difficult to implement, e.g. some Greek letters are transliterated differently depending on where they appear within the word, whether they are part of a diphthong, whether the language is Ancient Greek or Modern Greek, etc. That said, I am reasonably sure that we can do 99% of our Cyrillic titles automatically -- the other 1% are books written in non-Slavic languages that use a superset of Cyrillic.
A question for Uzume and/or Linguist: do you happen to know how easy it would be to come up with a deterministic romanization process for Japanese and perhaps some other East Asian languages? Ahasuerus 01:20, 29 January 2015 (UTC)
I stick by my earlier comments. It is true that it only doubles the maintenance when used (as such fields are not always useful; I never considered the disk space much of as real issue). I am for romanization fields but still think the literal English translation fields are of dubious usefulness. And rules for each language to use such fields need to be clearly specified for them to be usefully made use of. Uzume 18:46, 28 January 2015 (UTC)
Yes, it's a big issue. For example, the Cyrillic letter "ъ" is normally transliterated as " ("hard sign"). However, if it appears in the initial or medial position in a Bulgarian word, it is a vowel and is typically romanized as ŭ -- see my comments re: deterministic romanization algorithms above. Ahasuerus 02:03, 29 January 2015 (UTC)
Romanization fields could have automation to check that non-Roman characters cannot be entered (or at least severely flagged so it can be stopped at moderation time), however, we may want much leeway in what constitutes Roman/Latin script (e.g., allowing an assortment of diacriticals, etc. could be useful for some language romanization systems; some Japanese romanization systems use macrons and/or circumflexes). Uzume 18:46, 28 January 2015 (UTC)
This is one of the trickier issues that we will need to address. If we use macrons, circumflexes and other diacritics in the romanization scheme that we eventually adopt, will our users be able to enter them in the search box? And if we drop them, will the resulting transliterations be nigh unrecognizable to native speakers? (We are not the first to face this issue, of course, and the fact that no universally accepted scheme has been adopted so far suggests that no matter what we do, we won't be able to please everybody.)
If there is one bright spot in this picture, it's that we probably don't need to worry about "reversibility", i.e. the ability to do reverse transliteration, which tends to make transliteration algorithms noticeably more complex. Ahasuerus 02:25, 29 January 2015 (UTC)
I can understand the usefulness of English translations but I am not sure we need more than notes for this (do we really need to be able to search by these, etc.?). Uzume 18:46, 28 January 2015 (UTC)
The ability to search may not be particularly useful, but it would be nice to be able to see the translation as part of the mouse-over text described above. It's certainly not essential and, given the feedback so far, we may be better off concentrating on the romanization part of the proposal and postponing the translation part until a later date. Ahasuerus 02:18, 29 January 2015 (UTC)
I like Chavey's idea. Instead of using variants for alternative titles, pseudonyms, publishers, etc., it would be be better to have the records be nameless and be able to be associated with multiple names (variants might still be very useful for other types of relations like translations) much like multiple website URLs are handled now. These names need only to have a very few characteristics: the character string itself, language, and perhaps a script or something (useful for cases where some languages have used multiple scripts so we might have records of such; I am sure there are many but both Vietnamese and Korean come to mind). We could treat transliterations and transriptions such as romanization as another script and/or language pairing perhaps. We might also be able to flag some as translations (for the literal translation concept; we can still use variants for translated works which would have different names anyway). I well realize these sorts of concepts are considerable rearchitecting of the DB structure so are far from trivial (but that does not make them worthy of at least discussion and perhaps adoption one day). Uzume 18:46, 28 January 2015 (UTC)
If you need help coming up with a Japanese romanization scheme, I can help with that and work with whoever else is working on it. Nihonjoe 07:34, 22 February 2015 (UTC)

What is a "Stray Publication"?

Does anyone have a definition for this term? RR 21:34, 1 February 2015 (UTC)

"Stray publications" appear on Summary pages if there is a mismatch between the books' author(s) and the displayed author's pseudonym(s). They show up on one of our nightly "cleanup" reports and typically get corrected by moderators within 24-48 hours. Ahasuerus 21:48, 1 February 2015 (UTC)

Cover art links for dos-a-dos publications

The Publication Listing page has been modified to display one "Cover:" link per COVERART title. This will affect Ace Doubles and other dos-a-dos publications like see Adventures in the Far Future / Tales of Outer Space. Ahasuerus 05:11, 2 February 2015 (UTC)

How do you distinguish between their being one cover drawn by two artists (e.g. Diane & Leo Dillon) and the book being a double cover publications? I don't see anything inside the publication record that would differentiate those two cases, so are you using the "dos" Pub format to decide? Chavey 03:10, 3 February 2015 (UTC)
When there is a single work created by two artists (like the Dillons), there should be only one COVERART record. That relationship is displayed by the "and" connecting their credits. Of course, this has to be established manually, since the software automatically creates two records when a publication record is entered with two Artist credits. I suppose with this software change, it will continue to be handled manually. I don't see how we can safely merge the two COVERART records (since their author fields are different.) The only way I can see it being done now is that one will have to be deleted and the other one edited to add the second artist credit. Or has the software changed to do this automatically? Mhhutchins 03:54, 3 February 2015 (UTC)
No, this was a display-only change. There is a Bug that covers some of the same territory that Michael mentions above, but it's a dense thicket and will require additional thought. Ahasuerus 04:36, 3 February 2015 (UTC)
As an example, I just added the publication Eternal Moon, which gave credit to two people for the cover. But now the system believes there are two cover records. I've left it as is, as an example, but apparently what I would have to do to fix that is (1) delete one of the cover artists listed, and delete its title rec; (2) go to the title record of the other coverart title and add a second author to that record. Is that right? Chavey 08:16, 3 February 2015 (UTC)
I just checked with another book in that series, and the kludge I described above worked. If we're really going to keep a system where two authors listed for a cover create two different coverart records, then at least we should be able to enter a semi-colon list for a single cover, e.g. "Leo Dillon; Diane Dillon". Chavey 08:23, 3 February 2015 (UTC)
That would create a new artist with no connection to the individual artists. Until the bug has been fixed, the only option is (and has been for quite a while) to credit only one artist upon creation of the pub, and then update the COVERART record to add the second artist. Anyone who hasn't been doing that has been creating two records already, each one credited individually to the two artists. So essentially, as Ahasuerus said, the recent update is only a change in display, not a change in how the software works behind the scenes. Mhhutchins 16:44, 7 February 2015 (UTC)
I know that the idea of the semi-colon to separate two artists wouldn't work now (as Mike said, it would create a new artist with a long name). But we use the semi-colon to allow someone to enter multiple web pages in one field: The code handling that then splits them up. A similar approach here would require similar special case code for the cover artist. So it's possible, but non-trivial, and certainly not a function we have now. Chavey 20:31, 7 February 2015 (UTC)
Oh no, the use of semicolons as separators is no longer supported. It was an early kludge, which was zapped with extreme prejudice as soon as we added the "Add Web Page" button. Ahasuerus 00:39, 8 February 2015 (UTC)

(outdent) I would think a better approach would be to have a separate "add cover art" and "add cover artist" buttons. The first would create a new cover art record (the current behavior). The second would create a single cover art record with multiple artists. However, given all the other feature requests, I'm not sure I'd rate the need for this as all that high. -- JLaTondre (talk) 21:58, 8 February 2015 (UTC)

Yes, that's the approach that I proposed a few months ago. However, keep in mind that each cover art record can have multiple artists associated with it. So what we need is an "Add Cover Art" button which will create a new section which will contain a blank field for one artist and an "Add Cover Artist" button. Kind of like what we already have in the Content area and yes, it will be somewhat time-consuming to code. Ahasuerus 02:28, 9 February 2015 (UTC)

Improve "cover art" definition in help

When I started editing here I several times entered the one who did the cover design in the cover "artist" field. That was for books which don't have a real cover art but rather something like an "abstract art" concept, for example this and this publication. I later learned that the "artist" field is not for cover design. The help always talks about "cover art" (e.g. in the glossary) but never defines it. Though one might find it obvious that cover art is not cover design I think it's not that obvious and new editors will benefit from a more detailed definition/explanation. My suggestion: add something like this to the help:

"The cover designer is usually not entered in the "artist" field except when he or she also did (parts of) the cover art. However, the cover designer can be recorded in the note field." Jens Hitspacebar 19:05, 8 February 2015 (UTC)

Agreed. Template:PublicationFields:Artist would be a good place. -- JLaTondre (talk) 22:03, 8 February 2015 (UTC)
On occasion, the cover designer creates a montage (or the equivalent) out of other artistic elements, and that montage is what really creates the cover art. In such cases, I think that the cover designer deserves the appellation of a "cover artist", in the same sense that Freddie Baer is a montage artist. Chavey 16:31, 10 February 2015 (UTC)
Such a case would be covered by the "except when" part of my suggestion above. Hitspacebar 17:34, 10 February 2015 (UTC)
No more comments? No objections? Shall I had the suggestion to the Template:PublicationFields:Artist page? Jens Hitspacebar 20:01, 12 February 2015 (UTC)
Looks pretty good! Ahasuerus 04:54, 13 February 2015 (UTC)

Plain covers and image URL

I have a hard cover book with a plain cover. I don't know if there ever was a wrapper for it. Is there any point scanning the cover and uploading it? There is some information on the spine, I could make a larger scan to include it (or scan separately and merge images). Or I could scan the title page. Doug 19:45, 8 February 2015 (UTC)

If you search Google Images for the book, you can many times determine if it originally came with a wrapper (via people selling it, etc.). If it did come with a wrapper, then I don't see much point in scanning the wrapper-less cover. If it didn't come with a cover (or it cannot be determined if it did), then the the wrapper-less cover should be scanned. I don't see any point to scanning the title page (at least for uploading as the cover art). However, I'm not sure about any rules discussions on any of this. -- JLaTondre (talk) 21:50, 8 February 2015 (UTC)
With a few old books (e.g. 19th century books) that have only blank covers, I have used the title page instead of the cover. It has the (slight) advantage of specifying to a visitor "Yes, you have a copy of this book". A blank cover may, however, still fulfill that need for a visitor -- if they have a cover with an image or text, then they know it's not the one you've documented. Chavey 09:27, 10 February 2015 (UTC)

Here is the approach I've taken. The problem with searching for a wrapper is that you can never be sure of the match unless you also see the underlying book or have detailed publication information. Doug 13:22, 10 February 2015 (UTC)

I think that's a good solution -- that spine is the type of edition identifying information that we want for these pictures. Chavey 16:26, 10 February 2015 (UTC)

Andrew Offutt in the N.Y. Times

There was an extensive biography of Andrew J. Offutt in the New York Times Sunday, written by his son Chris Offutt, titled My Dad, the Pornographer. It discusses his 400 books written under 17 pseudonyms, mostly porn (and most of which we do not have listed under his bibliography here). It's quite a frank story, and I hesitate to link to it from his author page, but if you're interested in Offutt, or his bibliographic output, I recommend this article to you. Chavey 16:23, 10 February 2015 (UTC)

I saw that article. I don't think it would hurt to link to it, since a lot well known authors such as Silverberg, Ellison, Mike Resnick, etc., have all surfaced in the last few decades, and Earl Kemp has written extensively about it and the people involved.--Rkihara 19:15, 10 February 2015 (UTC)

Brief ISFDB downtime at 11pm server time

The next patch, which will change CHAPTERBOOKs to CHAPBOOKs, will be installed at 11pm server (US Central) time. It will require a brief downtime, hopefully around 5 minutes. Ahasuerus 04:47, 13 February 2015 (UTC)

All changes have been applied. Please report any issues or concerns here. Ahasuerus 05:04, 13 February 2015 (UTC)

Middle English option required

Hello. I'm afraid (again) that the local Linguist will require a Middle English option in order to enter a pub of the original version of Sir Orfeo and other 14th century spec-fic texts (Sir Gawayne, etc.). Thanks ! Linguist 12:51, 13 February 2015 (UTC).

When Middle English is added, we should correct the listing for the original Gawain and the Green Knight. Chavey 15:01, 13 February 2015 (UTC)
Done. Ahasuerus 18:56, 13 February 2015 (UTC)
Grete, þankes ! Linguist 12:34, 14 February 2015 (UTC).

2015-02-13 - Another brief downtime

I will be taking the server down at 9:30pm server (US Central) time to install the next patch, which will add support for "graphic" titles. The new data entry/display functionality will be similar to the previously implemented "non-genre" functionality except that there won't be a separate section for "graphic" titles at the bottom of the Summary page. Ahasuerus 03:14, 14 February 2015 (UTC)

Done. Ahasuerus 03:37, 14 February 2015 (UTC)

Make ISFDB links stable: create a redirect for merged (i.e. deleted) record ids

Merging records results in one (or more) of the their IDs being deleted. Now, if you happen to have linked to one of the records of the deleted ids from somewhere you end up on an "Unknown Title Record" page. Wouldn't it be a good idea to keep these ids (and only the ids) in the database and create a redirect to the merged record? As a result the ISFDB links could be considered stable and you would always end up on a page with a record (except when the last merged one has been deleted completely). That feature would need a new table with two columns "deleted_id" and "redirect_to_id" and the software to be able to redirect to the correct id. One thing to keep in mind is that subsequent merges of at title could result in a "redirect_to_id" to become a "deleted_id". Therefore the redirect would have to be able to hop from "deleted_id" to "redirect_to_id" to "deleted_id" to "redirect_to_id" until it finds one that exists. Jens Hitspacebar 16:41, 14 February 2015 (UTC)

This feature was requested back in 2009, although the proposed implementation details were different. I agree that the functionality is desirable since stable URLs are generally good to have. We may also want to consider implementing something similar for merged authors and merged publishers. Ahasuerus 17:15, 14 February 2015 (UTC)
Ah, thanks for the link to the FR. I should have looked there first. I tried to keep my idea above as "slim" as possible because I think keeping all the data of "merge-deleted" records might blow up the database size unnecessarily. However, if size is no problem then keeping all data of merged (and even completely deleted) records would be great. Hitspacebar 17:34, 14 February 2015 (UTC)
I have been thinking about this issue for the last few months and my inclination is to use the "slim" approach that you described. It's not so much the impact on database size that worries me as the fact that the data associated with merged titles may have been inaccurate. Ahasuerus 20:48, 14 February 2015 (UTC)
That's right. Lots of merges seem to be corrections of wrong data or simply duplicates therefore there's no real need to keep the deleted data. Hitspacebar 21:55, 14 February 2015 (UTC)
In the meantime, is it possible to create a cleanup report which finds bad links in title and pub records' note fields and author data webpage fields? (We have one for the pub record cover art field.) I recall someone creating a list of broken links and bad URLs in the past on a wiki page, but like everything else here I'm unable to find it. Mhhutchins 17:34, 14 February 2015 (UTC)
I guess it depends on what we mean by "bad links". On the one hand, although the software checks that entered COVERART URLs start with "http", it doesn't check that Title/Author/etc Web page URLs start with "http" or "ftp". As a result, we occasionally get mangled URLs like "www.ravenoak.net" on Raven Oak's Summary page or "trucksong.com.au" on the Trucksong milieu series page. It would be easy to add a few cleanup reports to find improperly formed URLs, although it would be even better to prevent editors from entering them in the first place as requested in FR 506. (Not that it happens very often since we currently have only 3 malformed URLs.) Ahasuerus 21:15, 14 February 2015 (UTC)
Every few weeks, I check for malformed URLs (along with broken Wikipedia links since they are easy to check using their API) using a database dump. I usually clean-up 2-3 malformed URLs each time. It's in the range that it's easy enough to manually fix, but it is frequent enough that if it wasn't regularly being checked it would grow into a significant number. -- JLaTondre (talk) 20:00, 16 February 2015 (UTC)
On the other hand, there are many properly formed URLs that take you to Web pages which are either temporarily down or are no longer valid. The only way for a cleanup report to check the current status of our URLs is to query each and every one of them. With over 79,000 URLs currently in the database, it's not something that the nightly process can realistically do every night. In addition, some sites frown on robots requesting pages too frequently, so we would have to be careful to avoid problems with places like sff.net, which hosts 169 SF author pages. It's doable, but not trivial, which is why the Publications with Suspect Images report is handled by Fixer on an annual basis. I will look into enhancing it to handle other types of URLs. Ahasuerus 21:15, 14 February 2015 (UTC)
A general URL scanner is difficult, but checking self-links within ISFDB notes (keeping in the spirit of the original request about deleted ids) is easy enough to do since one can just check if the applicable database record is present. I dusted off some code and checked the last database dump. The results are below. -- JLaTondre (talk) 20:00, 16 February 2015 (UTC)

Bad ISFDB Links in Notes

The following lists cases where a ISFDB URL is present within a notes field, but the URL points to a database record that doesn't exist. Each line identifies a non-existent database record and then has link(s) to the record(s) whose notes field links to the non-existent record.

The following lists cases where a ISFDB URL is present within a notes field, but the URL is either malformed or uses an edit link vs. a display link. Each line lists the problematic URL then has a link to the record whose notes field links to that URL.

  • http://www.isfdb.org/cgi-bin/edit/editpub.cgi?256426 : 256430
  • http://www.http://www.isfdb.org/cgi-bin/pl.cgi?WHLWRLDJBR1981 : 263073
  • http://www.http://www.isfdb.org/cgi-bin/title.cgi?883353 : 294845
  • http://www. isfdb.org/cgi-bin/pl.cgi?225 : 1072
  • http://www.isfdb.org/cgi-bin./pl.cgi?25734 : 263146
  • http://www.isfdb.org/.cgi-bin/pl.cgi?349740 : 350294
  • http://www.isfdb.org/cgi-bin/edit/editpublisher.cgi?23813 : 39459
  • http://www.isfdb.org/cgi-bin/edit/editpub.cgi?416685 : 416685
  • http://www.isfdb.org/cgi-bin/edit/editpublisher.cgi?11131 : 22549
  • http://www.isfdb.org/cgi-bin/edit/editpublisher.cgi?33944 : 34345
  • http://http://www.isfdb.org/cgi-bin/title.cgi?1712681 : 1784354
  • http://www.isfdb.org/cgi-bin/pl.cgi? : 498366

I think the need for some of these links is debatable (ex: linking previous / next magazine issues given the software already supports magazine navigation), but if we're going to have them, it would be better to have working ones instead of confusing readers. -- JLaTondre (talk) 20:00, 16 February 2015 (UTC)

Great, thanks! If you would like to share the code, I can incorporate it into the nightly job that generates cleanup reports. Ahasuerus 02:44, 18 February 2015 (UTC)
The script is in Perl and was put together pretty quickly. I know the site is in Python. If you are fine using a Perl script, I can make it more production worthy. Or if you'd prefer to rewrite in Python, I can pass along as is (with some additional comments) and you can use as pseudo-code. I can also look at redoing it in Python, but that would be a bit longer as I've only dabbled with it. -- JLaTondre (talk) 21:44, 19 February 2015 (UTC)
If you send me the Perl code, I may be able to convert it to Python. My exposure to Perl has been limited, but I used it at various points in the past. My e-mail is (redacted). TIA! Ahasuerus 22:37, 19 February 2015 (UTC)
Sent. Let me know if you have questions. -- JLaTondre (talk) 00:34, 20 February 2015 (UTC)
Got it, thanks! Ahasuerus 00:45, 20 February 2015 (UTC)

2015-02-15 downtime at 8pm server time

I will be taking the server down at 8pm server (US Central) time to apply the next patch, which will change the default values of the 'Non-Genre' and 'Graphic' flags from [nothing] to 'No'. With luck, we should be back up within 5 minutes. Ahasuerus 01:47, 16 February 2015 (UTC)

Done. Ahasuerus 02:05, 16 February 2015 (UTC)

NewPub changes

Based on editor feedback, I have moved two fields -- Publication Type and Year -- from the Title Data section of the NewPub page to the Publication Data section. Ahasuerus 04:51, 16 February 2015 (UTC)

Yes, much better. That clears up the conflict of whether the date field is for the publication or the title. Thanks. Mhhutchins

Slashes in series names

As per Help:Screen:EditSeries:

  • ... a series can have only one name, so if two or more names are equally well known (e.g. one name is used in the UK and another in Australia), the only option is to list them all in a slash delimited format, e.g. http://www.isfdb.org/cgi-bin/pe.cgi?1455

Since "a slash delimited format" can be interpreted differently, we have 374 names which use the "A / B" format and 120 names which use the "A/B" format. Do we want to standardize one way or the other? If so, it would be easy to create a cleanup report to find non-compliant series. Ahasuerus 06:31, 16 February 2015 (UTC)

It should be standardized with a cleanup report to find the nonstandard uses. I believe the space around the slash makes for a clearer understanding that there are two series names. So that gets my vote. Mhhutchins 19:08, 16 February 2015 (UTC)
Ditto. -- JLaTondre (talk) 19:11, 16 February 2015 (UTC)
Here also a vote for more space. Stonecreek 19:18, 16 February 2015 (UTC)
Also in favor of the spaces. Chavey 19:38, 16 February 2015 (UTC)

(unindent) Sounds good. Now, what about series names like Haruhi Suzumiya (light novels/stories)? Should we keep "novels/stories" as is since the slash is not used to separate series names? If so, I will add the ability to "ignore" series records to the report that I am currently working on. Ahasuerus 21:24, 16 February 2015 (UTC)

Further digging found a number of other questionable cases, so I went ahead and added the ability to ignore series records to the report. The software has been deployed and moderators will see the results after the next run of the nightly job. Ahasuerus 21:51, 16 February 2015 (UTC)

Display of VT languages tweaked

As per FR 782:

  • [the Summary Bibliography logic will now] display VT languages if the parent has no language defined and the VT language is not English. The vast majority of our non-English titles have been entered since we added support for language codes, so it's highly likely that a non-English VT of a language-less parent is a translation.

Ahasuerus 19:44, 16 February 2015 (UTC)

That is probably a good guess until further information is provided. Thank you. Uzume 06:14, 19 February 2015 (UTC)

"Graphic" -> "Graphic Format"

Based on our brief experience with the recently added "Graphic" field, its name has been changed to "Graphic Format". This affects New Publication and Edit Title as well as the regular Title and Publication display pages. Ahasuerus 00:36, 17 February 2015 (UTC)

Perhaps we need to create a standard for when this flag should be used. Other than the CHAPBOOK title record for a graphic novel, where else should it be used? Is it used for the INTERIORART and SHORTFICTION content records? Is it to be used for comic strips and other graphic story contents in an ISFDB-eligible publication? Is it to be used to type a COLLECTION and ANTHOLOGY of graphic stories?
And again, we need to make it clear that graphic novels, collections and anthologies should only be entered when the responsible author is an "above-the-threshold" author already in the database. (Just as we do for non-genre publications.) This doesn't include adaptations by other parties by authors and artists that are not eligible otherwise for the database. This might include for example, a graphic novel adaptation of Isaac Asimov's "Nightfall" by an ineligible author and artist. Or do we now break down completely the firewall between the ISFDB and graphic novels and stories? I suppose these questions are probably more suited for the Rules and Standards discussions page. If enough editors feel it's debatable, I'll start a topic there. Mhhutchins 02:27, 17 February 2015 (UTC)
The original intent of this FR was to distinguish between regular prose novels and graphic novels. I thought it was especially important to draw this distinction when the same author was responsible for two different versions of the same story, e.g. consider Neil Gaiman's "Coraline" books. Now that the feature has been implemented, we can decide what other circumstances warrant its use.
Personally, I think that it can be profitably used in conjunction with NOVELs, CHAPBOOKs, SHORTFICTION, COLLECTIONs, ANTHOLOGYs and, I suppose, OMNIBUSes. The following title types won't let you edit this flag: INTERVIEWs, REVIEWs and, as of 15 minutes ago, COVERART and INTERIORART. Actually, now that you have raised the point about INTERIORART titles associated with graphic novels, I am having second thoughts about it. The good news is that it will be easy to undo the change if that's what we decide to do.
In any event, yes, let's copy this discussion to the Rules and Standards page and see where it takes us. Ahasuerus 04:03, 17 February 2015 (UTC)
I have used the flag on an art book by Graham Oakley, otherwise it would have been pure NONFICTION. I thought it was intended also for that use, wasn't it? Stonecreek 04:33, 17 February 2015 (UTC)
Not under the current standards. I assumed the new flag was intended for a story told graphically. A collection of unrelated artwork without any fictional conceit wouldn't qualify in my opinion. They've always been entered as NONFICTION. But I guess that's open for discussion. Mhhutchins 04:56, 17 February 2015 (UTC)

(unindent) It occurs to me that those of us who haven't been exposed to the world of comic books may be unaware of the way the term "graphic novels" is used. A "graphic novel" is simply a standalone comic book. The only reason that publishers, librarians, etc do not call them "comic books" is that the latter terms is reserved for comic books which appear as periodicals. The term "graphic novel" can be used to describe a chapbook, a manga book (although apparently some people consider mangas a separate format), a collection/anthology of comic stories, etc. Basically anything that is (a) a comic and (b) not a periodical.

Based on the above, perhaps we should change the "Graphic Format" flag to "Comic Format" in order to avoid confusion? Ahasuerus 16:23, 17 February 2015 (UTC)

I don't think you can rule out "periodicals" as graphic novels. I have the first 15 issues of "Akira", a cyberpunk manga graphic novel, and the first couple of dozen issues of "Lone Wolf and Cub", also a manga graphic novel. These are continuing stories, but are still viewed as graphic novels. I checked Paul Gravett's "Graphic Novels: Stories to Change Your Life", and he refuses to try to define them. Often, the difference between a "comic book" and a "graphic novel" is whether it's perfect bound or not (but I certainly wouldn't want to use that as a definition). Generally, the difference is the intended audience: juvenile vs. adult. Wikipedia starts by saying it's "a fictional story that is presented in comic-strip format and presented as a book", but then goes on to say it can mean lots of other stuff as well. I still prefer the term "graphic novel" or "graphic format" over "comic format", but rather than trying to define what either one means, it might be easier to just link to Wikipedia. Chavey 21:37, 17 February 2015 (UTC)
I know little about comic books, graphic novels and their cousins, but it was my understanding that when comics people state that "comic books" are limited to "periodicals", they mean periodicals as in "periodically published magazines", which may or may not contain continuing stories. For example, Captain Marvel Adventures #149 contained 5 seemingly unrelated stories (just like a magazine would), but remained a "comic book". Ahasuerus 01:17, 18 February 2015 (UTC)
That's fine except that the standards have been for awhile that only the collected issues of a comic book (first published periodically) are eligible for the database. (And then only if the author is eligible.) That's why the 12 issues of Watchmen don't have records, but the combined publication has one. Also, the ISFDB doesn't have standards based on a publication's intended audience.
Back to the naming: I don't think we're trying to define the term "graphic novel". We're trying to come up with a term for all forms of eligible content which are more illustration than text. I don't like "comic format" and I suspect most readers of graphic novels have the same feeling. Similar to my dislike of "sci-fi" (unless you pronounce it "skiffy"). Mhhutchins 23:24, 17 February 2015 (UTC)
But wouldn't the problem with a generic definition like "eligible content which are more illustration than text" be that it would also cover NONFICTION art books? Ahasuerus 01:01, 18 February 2015 (UTC)
I left out "fictional". Again, I wasn't trying to come up with a definition for "graphic novel". Wasn't the purpose of this post to find a type-name for everything that falls under the category of a fictional work told with illustrations and limited text regardless of its length? So far we've come up with 1) "graphic novel", 2) "graphic format" and 3) "comic format". If no other suggestions arise, I'd go with number 2. I don't want to waste any more of my time worrying about the name of something that most of us can point to and say "that's one", especially since very few of them are actually eligible for the database under the current standards. Mhhutchins 01:13, 18 February 2015 (UTC)
Well, the addition of the "Graphic" flag has raised the visibility of this issue and possibly reopened some moldy cans of worms. I think one way to get everyone on the same page and make the "Graphic Format" field less confusing would be to add the current eligibility rules to the newly added Help templates (1 and 2). We can also add the same language to the mouse-over help. If that does the trick, great. If not, then we can revisit the issue. Ahasuerus 02:10, 18 February 2015 (UTC)
Picture Books, too? ("more illustration than text", but not like a comic; e.g. Gaiman & McKean's The Wolves in the Walls [1]) --clarkmci / j_clark 09:38, 18 March 2015 (UTC)

Help:NewNovel folded into NewPub

FYI, the "NewNovel" Help page has been folded into "NewPub". This should help eliminate duplication of information and reduce the chances of Help pages getting out of sync. Ahasuerus 01:52, 17 February 2015 (UTC)

ISBN searches fixed

The regular ISBN search has been fixed not to error out when trying to display publications without publishers. In addition, the layout of the table that contains search results has been adjusted to be in line with other searches. The columns for publication record numbers and "publication tags" have been eliminated. Ahasuerus 20:00, 17 February 2015 (UTC)

Cool! Now if we could just get searches to use GETs instead of POSTed forms (then we would not have to resubmit search POST searches and could even bookmark them, etc.). HTTP POST was designed for making updates/changes to data and searches should never change anything. Uzume 06:11, 19 February 2015 (UTC)
I can't think of a reason not to convert it. Let me play with it... Ahasuerus 02:08, 20 February 2015 (UTC)
Bookmarking searches and not having to refresh search results would be wonderful. (I think that last part is what you meant by having "not to resubmit POST searches", since I'm not sure what a POST actually is.) Mhhutchins 02:23, 20 February 2015 (UTC)

Restrictions on "Edit Publisher" lifted

"Edit Publisher" has been made available to all editors. We need to create a new help page, but the fields are pretty much self-explanatory if you are familiar with other data entry forms. Please note that only moderators can change publisher names at this time. Ahasuerus 03:43, 18 February 2015 (UTC)

Two different David Mitchell author records necessary?

I just wondered if the INTERIORART records for David Mitchell is really the same person that was responsible for the other title types. He would have been 10 years old when the artworks were published. Not impossible, but not very likely. I tied some web searches but didn't find anything useful, except that I didn't find a site mentioning the author David Mitchell was also a painter. Hitspacebar 17:50, 18 February 2015 (UTC)

The artist should be disambiguated. I'll do it. Thanks for finding this. Mhhutchins 17:58, 18 February 2015 (UTC)

Advanced Publication Search enhancement

Advanced Publication Search has been enhanced to support searches by publication type ('NOVEL', 'COLLECTION', etc). Ahasuerus 03:09, 20 February 2015 (UTC)

Standardizing wildcards in searches

There is a discrepancy between the way Search and Advanced Search handle wildcards. With regular Search, if you enter "heinl%n" in the search box, the resulting list will include all of our "Heinlein" records. In Advanced Search, you need to enter "heinl*n" in order to get the same results. (The underscore character, "_", matches a single arbitrary character in both cases.)

It seems obvious that we should standardize wildcard behavior, but first we need to decide whether we should go with "*" or with "%". "*" is a much more common wildcard character used by Windows and other operating systems. Besides, it is currently listed on the Advanced Search page as our "official" wildcard character, so it appears to be the stronger contender. Would anyone disagree? Ahasuerus 04:59, 21 February 2015 (UTC)

* has been the Unix wildcard character since 1969, so I have a strong preference for it. The 1978 "Unix rewrite" of Star Wars replaced the "Death Star" with "Arem Star" (You see "rm" was the command to "remove" a file, so "rm * " removed ALL files. Ok, maybe you had to be there :-) Chavey 06:35, 21 February 2015 (UTC)
"*" is the better choice for the reasons given above. However, another approach could be to accept both characters equally in all search boxes and let the users make their preferred choice. Hitspacebar 08:02, 21 February 2015 (UTC)
"%" is the SQL zero-or-more wildcard character, and "_" is the SQL any-one wildcard. I doubt most of our user community would be aware of either. I like the idea of accepting asterisk and SQL wildcards, but I do think it would be good if "*" were accepted everywhere. --MartyD 12:03, 21 February 2015 (UTC)
Thanks, FR 790 created. Ahasuerus 22:10, 23 February 2015 (UTC)

Help:Using HTML in Note Fields

Please note that Help:Using HTML in Note Fields has been updated with a list of deprecated URL formats to avoid. Ahasuerus 20:49, 25 February 2015 (UTC)

This section is especially important to keep in mind when linking to authors and pub records in the database. This clean-up report shows titles and pubs with malformed URLs in their Note fields. Keep in mind that just because it's "linkable" doesn't make it a valid URL. I only recently discovered this. Just because the links worked in the past and the URL entry was valid then, doesn't mean the URLs are valid now. If you see any publications on the clean-up report which you entered, please take the time to correct the URLs. Thanks. Mhhutchins 22:00, 25 February 2015 (UTC)
The report is only available for sysops. Doug 13:34, 26 February 2015 (UTC)
The link to the report was for moderators, but the remaining information in the post applies to everyone, who should read the Help section to which I linked. Thanks. Mhhutchins 18:42, 26 February 2015 (UTC)
I read the help and am guilty of making references to other publications in some of my entries. I am unsure which format I used or which entries made the reference. I was hoping I could use the report to pinpoint which publications I needed to check and correct. Doug 13:50, 27 February 2015 (UTC)
I am afraid all of our "cleanup reports" (83 at last count!) are moderator-only. Many of them let the reviewer "ignore" individual records, i.e. permanently remove records from the report, and we wouldn't want to make this ability available to newly registered users. Perhaps I should go back, make the reports available to everyone and limit the use of the "ignore" option to moderators. Ahasuerus 05:35, 28 February 2015 (UTC)

Paging All Elfquest Experts!

According to Wikipedia, the Elfquest books are mostly comic books/graphic novels with some prose novels in the mix. Our Wendy Pini Summary page lists quite a few of them and I suspect that many are graphic novels or reprints of comic book material.

Do we happen to have anyone on board who would be able to review these titles and sort things out now that the "graphic format" flag has been added? Ahasuerus 04:03, 26 February 2015 (UTC)

I spent the better portion of a day a couple of years back cleaning up the Pini (both Wendy and Richard) summary pages. All of those titles under CHAPBOOK are comic...er...graphic novels. The last I looked there were only three prose novels in the Elfquest series, those now numbered 1 - 3 in the series list. The ones currently entered as NOVEL and titled as Elfquest Reader's Collection are compilations of various single issues of the comic book...er...graphic novel series, four or so issues per volume. I left them typed as NOVEL, because I didn't think we should enter individual issues as content records in each of them. Still don't. (Just like Watchmen is a NOVEL and not a COLLECTION, even though it was published serially in twelve issues.) I'm not sure that we now have the graphic format flag that they should be typed differently (as COLLECTIONs), just flagged as graphic. There may have been some publications added since I worked on them, but the page is in helluva lot better shape than before I got to it. I'll leave the fine-tuning to someone who is familiar with the comic books...goddamn it...graphic novels. Mhhutchins 04:34, 26 February 2015 (UTC)

Booktopia and Fishpond added

Two Australian bookstores, Booktopia and Fishpond, have been added to the list of "Other sites" that we automatically link to. In addition, the display logic has been reworked to show these sites alphabetically. (Similar changes were made to the list of "Other Sources" which moderators see on the New/Add/Clone Publication review page.) Ahasuerus 05:31, 28 February 2015 (UTC)

Ooh! Handy. Note however, that lately Fishpond's prices are often significantly above the recommended retail price from the publishers, but still is a nice "sanity check" having in on the list. --clarkmci / j_clark 09:52, 5 March 2015 (UTC)
I was wondering about that :) Ahasuerus 15:02, 5 March 2015 (UTC)
Angus & Robertson on-line seems better for prices. I'm not familiar with Booktopia, so can't comment there. --clarkmci / j_clark 09:52, 5 March 2015 (UTC)
Thanks, I have created an FR to link to Angus & Robertson. Ahasuerus 15:02, 5 March 2015 (UTC)
Done! Ahasuerus 06:37, 7 March 2015 (UTC)
Lovely! Thank you. --clarkmci / j_clark 07:40, 7 March 2015 (UTC)

Brief ISFDB outage

The weekly backup process failed a few hours ago and needs to be re-run, which will require a brief outage. I will take the database down at 1:15pm server (US Central) time and hope to have it back up around 1:30pm. Ahasuerus 19:07, 28 February 2015 (UTC)

Everything should be back to normal. Ahasuerus 19:40, 28 February 2015 (UTC)

Middle High German option required

Hello. Guess what ? It would be great to have a Middle High German option in order to edit the original text of the Nibelungenlied. Thanks ! Linguist 09:55, 2 March 2015 (UTC).

Sure, I'll take a look tomorrow. Ahasuerus 05:48, 3 March 2015 (UTC)
Done. Ahasuerus 01:03, 4 March 2015 (UTC)
Thanks a lot ! Linguist 11:24, 4 March 2015 (UTC).

"Fantastic Beasts and Where to Find Them", by J.K. Rowling

This book has been verified as both a Collection and as a Novel, which causes problems in the cleanup reports. It's clearly not a novel, because it's only 42 pages long. It's fundamentally a collection of "in-universe essays" about the various beasts, with a linking narrative provided by "notes" left by Harry, Ron, and Hermione, giving a sort of implied plot running alongside the text. So it's sort of a collection, and sort of a novelette chapbook. But whatever we call it, we should all call it the same thing. Thoughts? Chavey 07:35, 4 March 2015 (UTC)

I had just changed the title record to COLLECTION & was part way through changing the first of my editions to collection (with selected contents) - based on a discussion on rtrace's page [2] - when I saw this. --clarkmci / j_clark 07:46, 4 March 2015 (UTC)
Later: my take on the collection contents - here
Oops. Looks like all the necessary conversation is happening over there; no need for followups here. Chavey 16:25, 4 March 2015 (UTC)
Clark, it appears you clicked on the wrong entry type. Surely it's not supposed to be a FANZINE. Mhhutchins 18:24, 4 March 2015 (UTC)
It's now showing up on three different clean-up reports. I'm going to change it from FANZINE to COLLECTION. Mhhutchins 07:51, 5 March 2015 (UTC)

Phython script problem

I have been confronted with this sinister message :

<class 'xml.parsers.expat.ExpatError'> Python 2.5: /usr/bin/python Sun Mar 8 09:04:09 2015
A problem occurred in a Python script. Here is the sequence of function calls leading up to the error, in the order they occurred […].

five or six times in a row after submitting an edit (adding a new collection), which I re-did completely (thinking I had made an error somewhere). I met that problem before, but never that long… I have left the last submission pending after cancelling all the others. Linguist 14:09, 8 March 2015 (UTC).

It looks like the problem is with the currency sign in the "Price" field, which reads "▒1.50". A copy-and-paste artifact, perhaps? I'll review the code to see if we can prevent these types of invalid characters from being entered in the first place. Thanks for reporting the problem! Ahasuerus 16:17, 8 March 2015 (UTC)
Thanks for your answer. I had typed the price myself, using the usual £ symbol. But maybe something like an extra invisible character got in the way… Linguist 16:46, 8 March 2015 (UTC).
It went through after I re-typed the £. Thanks agains. Linguist 16:50, 8 March 2015 (UTC).
It turns out that in this case the pound sign was preceded by the "file separator" character. This character is not valid in XML and our submissions are stored as XML, so when the display logic tried to parse the submission, it errored out. Checking the XML standard, I see that there is a couple dozen characters like that. Tomorrow I will try to change the data entry logic to strip them silently. Ahasuerus 03:46, 12 March 2015 (UTC)
OK, the logic has been adjusted to prevent these types of problems in the future. The change wasn't quite as straightforward as I had thought, but hopefully nothing got broken. As always, if you see anything unexpected, please post your findings here. Ahasuerus 02:02, 13 March 2015 (UTC)

Review/Interview bug fixed

Entering spaces (and nothing by spaces) in Reviewer, Interviewer and Interviewee fields should no longer result in unapprovable submissions. Ahasuerus 23:13, 9 March 2015 (UTC)

Advanced Search bug fix

Earlier today a Usenet poster reported a Python error when manually manipulating Advanced Search URLs. At first I was concerned that it may indicate a security vulnerability that would let an attacker modify/delete the ISFDB database, but it turned out to be relatively harmless. Still, a bug is a bug is a bug, so I made a number of changes to the Advanced Search logic to fix it. If you see anything unusual in the way Advanced Search functions, please post your findings here. Ahasuerus 02:12, 12 March 2015 (UTC)

2015-03-15 performance issues

I am aware of sporadic server freezes, but I haven't been able to determine the root cause. I don't see anything affecting the system that would be under our control. Ahasuerus 05:11, 15 March 2015 (UTC)

ISFDB downtime 2015-03-15 at 7pm server (US Central) time

The server will be unavailable between 7pm and 7:05pm server (US Central) time. Ahasuerus 23:53, 15 March 2015 (UTC)

Sorry, folks, I was sidetracked and unable to perform maintenance at 7pm server time. I will do it at 7:30pm, in approximately 8 minutes. Ahasuerus 00:22, 16 March 2015 (UTC)
Retrieved from "https://isfdb.org/wiki/index.php?title=ISFDB:Community_Portal/Archive/Archive35&oldid=396937"