ISFDB:Community Portal/Archive/Archive36

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

Expanded archive listing

Archives of the community portal for April - June 2015

Suggestion for a correct sort order of multiple printings of a publication when date is not known

I just came across another case where I couldn't find any information about the publication date for the second printing of a book and had to enter it as "0000-00-00" - which results in wrong ordering in the list of publications ("0000" for the second printing comes first). Suggestion: add the possibility to sort the publications by adding a "fake" date to the "0000-00-00" - similar to the possibility to sort the titles in collections. Example:

Year of first printing, known because of reviews, publisher's catalogue etc: "2009-03-01"
Year of second printing not known, but obviously has to be later than the first printing: "0000-00-00|2009-03-02"

The software would use the date behind the pipe for sorting if it exists and as a result, the second printing would appear below the first printing in the list.

Jens Hitspacebar 16:35, 28 February 2015 (UTC)

Ah, well, I just realized it's a DATE field, where the pipe solution will not work. Hm. Jens Hitspacebar 17:32, 28 February 2015 (UTC)

Not quite the same thing, but FR 491 covers similar territory. Ahasuerus 19:00, 28 February 2015 (UTC)

I think that FR would be an improvement. It would still be nice to be able to break ties, though. I'm thinking of books like The Magicians of Caprona, where all we know about the first US & UK editions are "1980-00-00", but for other reasons we know which one came first. Or "0000-00-00" dates, where the 3rd printing certainly came before the 4th printing. Some editors have used fake dates to force the order, which is unsatisfying, but some way of specifying an ordering would be helpful. Chavey 22:24, 28 February 2015 (UTC)

Maybe a second DATE field called "date_sort" would be a solution. It'd be optional and only accepted if a publication date has been entered as well. If set it would be used for sorting. Jens Hitspacebar

If we're adding fields, why not a printing field? If I'm searching for a match to a publication I have in hand and I don't know the date, I'm checking for publisher and price. Then I check contents to see what printing it was. If printing were part of the publication list, I'd be happy. The sort date works for a single published format, but when you get multiple and don't know dates, you're really just guessing anyway. Doug 13:51, 2 March 2015 (UTC)

I'm also interested by a "printing rank" field. Hauck 14:36, 2 March 2015 (UTC)

This was discussed a few years ago and I thought we had an FR to add a "printing" field, but apparently not. Now we do :-)

Once we add it, the software should be able to do more intelligent sorting by date/publisher/printing. It will not be perfect because printing sequences may span multiple publishers, but it should be better than what we have now. Ahasuerus 15:08, 5 March 2015 (UTC)

I had always held on requesting a printing field as while it would greatly help in the grouping and sorting there were several aspects that seemed to cause pain:

We are not consistent in publisher names and/or publishers change their name slightly while continuing a printing series. The fix for this would be to add a field that points to the record for the first printing. If someone does not fill in the field then we'd use publisher name matching.
There are a large number of publications where we can only assume it's the first printing. They don't have number lines. Would we enter these as "1" in the printing field but also include a note that the printing is not stated? Perhaps we could enter "0" or some other special code.
I'm guessing we would enter "9" if a publication says "Ninth printing, October 1978" and that it would get grouped under the first printing but with a date?
How do we handle publications that use a letter line? For a while DAW Books had a word line where they spelled out "First" "Second" "Third". Would these get normalized to Arabic numbered 1, 2, 3?
How do we handle what appear to be later printings but they don't have a printing number?

--Marc Kupper|talk 15:57, 4 April 2015 (UTC)

All reasons why implementing a printing field would create more problems than the need to sort publications. An undated publication is an undated publication. Why make an attempt to sort it within those which are dated, or even within those at the end of the list which are not dated? My wish for a software change would be easier to implement: all unmonthed (only year dated) publications should be sorted as month-dated "13" unstead of "0" as it is currently. That way a later printing dated the same year as the first (but unmonthed) would not be displayed before the day and/or month dated first printing as it does now. Mhhutchins 17:53, 4 April 2015 (UTC)

Birth Place: Ireland

In general, we try to abide by our rule that "For locations whose names have changed over time, use the name as of the time of the author's birth". For Ireland, we use "Kingdom of Ireland" up to 1801, then "Ireland, UK" up to Dec. 5, 1922. From there, Northern Ireland has been consistent, but the larger part of the country has had three names: "Irish Free State" from 1922-12-06 to 1937-12-28; "Ireland" from 1937-12-29 to 1949-04-17; then "Republic of Ireland" from 1949-04-18 to the present. However, we clump together those three names as "Ireland". Should we? Chavey 10:23, 31 March 2015 (UTC)

I guess there is a larger issue here. Technically, Mexico is "United Mexican States", France is "the French republic", Germany is "the Federal Republic of Germany", Russia is "the Russian Federation", Italy is "the Italian Republic", etc. I think that using these official names would be an overkill. Ahasuerus 17:01, 31 March 2015 (UTC)

Thanks for the confirmation. I had just spent a bunch of time getting pre-UK date places listed properly, and was then worried that I was being OCD about the pre-1807 names, while ignoring later name changes. I think it's still pretty subjective, for example, to distinguish between Kingdom of Ireland/United Kingdom/Ireland, but not to distinguish between Irish Free State/Ireland/Republic of Ireland, and I certainly wouldn't want to have to write up rules to say when we pay attention to name changes, but I'm comfortable with going with "intuition" on when a change is significant enough to be reflected in our Birthplace names. Chavey 17:37, 2 April 2015 (UTC)

Stable links to the BLIC

I was surprised to read on Help:Using HTML in Note Fields#Links that to to the British Library Integrated Catalogue (BLIC) are not stable. If you are looking at a BLIC record such as this one for Science fiction by Mark Bould there's a "send to_v" in the upper right corner. If you right click on that and copy the link address then you will get a stable URL to that record. You can also use the E-mail feature and will get an e-mail that contains a stable link. Here are examples of links for the same record using Send-to and e-mailing the record to myself:

Send to	http://catalogue.bl.uk/primo_library/libweb/action/dlDisplay.do?vid=BLVU1&afterPDS=true&institution=BL&docId=BLL01016048936#
E-mail	http://catalogue.bl.uk/primo_library/libweb/action/dlDisplay.do?vid=BLVU1&afterPDS=true&institution=BL&docId=BLL01016048936

I'm wondering if this method is too mysterious to be documented? --Marc Kupper|talk 20:15, 4 April 2015 (UTC)

On October 9, 2013, I made a post to the Community Portal that all links to BLIC in the database should be removed because they were session-based and disappeared within 24 hours. After much research and testing, on November 12, 2013, I made another post which explains how one could create a stable link to an BLIC record. There are still hundreds of records in the database which use the first method and still need to be fixed. The primary verifiers of those records, and any conscientious ISFDB editor who comes upon them, should fix them using the method I described there. I will repeat that method here:

This link searches for BLIC record number 1234567890:

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

Just replace "1234567890" with the BLIC system number and it links properly. For example in this record, I entered "011983806".

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

Of course, this requires that an editor first search for the record on BLIC, and once finding it, create an HTML link in the ISFDB record's Note field to the record on the BLIC website. At least one editor (SFJuggler) uses the method I describe, and I've seen no problems with the links in his notes.

I believe the method I describe is simpler and more direct than the one that Marc describes, though I'm not doubting that both works. I will add the method I discovered to the HTML help page. Thanks for pointing it out, Marc. Feel free to provide any alternative methods. Mhhutchins 16:46, 5 April 2015 (UTC)

Your method seems simple enough though your example confused me a little. From A Feast Unknown you linked to System number 011983806 is for A feast unknown : volume IX of 'The memoirs of Lord Grandrith', edited by Philip José Farmer. A better record seems to be BLIC BLL01016118308.

One difference is Mhhutchins' method shows a search result and you then click the title and then the "details" tab to view the record. I was showing how to get a direct link to the record's details. In looking into this more I found a simpler process. The UIN is shown as the last line in the details of every record. You append the UIN to http://catalogue.bl.uk/primo_library/libweb/action/dlDisplay.do?docId= to construct a direct link.

For exaple, If I search the BLIC for 'falling free bujold' it shows the search results for one record. I click 'details' in the search results. This shows the details in a frame with a scroll bar. Scroll to the bottom and the UIN is BLL01010084954.

http://catalogue.bl.uk/primo_library/libweb/action/dlDisplay.do?docId=BLL01010084954 is the direct link to the record for the publication Falling Free.

It appears you can convert a BLIC system number into an UIN by prefixing the system number with 'BLL01'.

Here are examples of linking using the system number vs. the UIN:

and:

--Marc Kupper|talk 23:05, 5 April 2015 (UTC)

Windy City Pulp Convention

I'll be attending the Windy City Pulp Convention this month. If anyone from the ISFDB is attending, would you like to meet for a drink?--Rkihara 20:04, 9 April 2015 (UTC)

Minor changes to the Tag Editor page

When I started working on making the Legal Name field a repeating field (similar to tags, email addresses, Web pages, etc.) I found that different fields behaved in subtly different ways. This is a bad thing for a number of reasons, so I have been working on standardizing the way these fields are handled.

As a side effect of my work, the Tag Editor page looks somewhat different now. Specifically, the field label is a little different and the field length is different. In addition, mouse-over help has been added. Ahasuerus 22:21, 9 April 2015 (UTC)

What kinds of awards do we want to support?

(copied from the Help desk)

The Moonbeam Children's Books Awards (Goodreads, Facebook, Wikipedia) are an interesting case, which may have wider implications. The organization that runs these awards charges authors an entry fee, $85 at this time, if they want their book to be considered. So are they really awards as we know them or are they a promotional tool? As one Web site puts it:

Every year, a round of book contest award programs is launched, and every year, on may publishing fora, a battle is waged regarding if the contests are worth it. [...] There are a lot of companies making a lot of money off contests. Most are “beauty pageants” where every entrant wins a nominal prize just for entering their book(s). Who really wins? Well, the promoter of said prize contest. Figure that at least 2500 people will pony up $50 or more for their book to be considered. Post a website and print 2500 certificates, and you’ve made an 85% profit. And most of the people participating are perfectly happy.

Do we really want to list "contest awards", especially if authors have to pay a fee in order to submit their entries? Ahasuerus 01:39, 13 April 2015 (UTC)

I don't think any effort should be made to add these "contest awards" to the database. Mhhutchins 02:02, 13 April 2015 (UTC)

Ditto. PeteYoung 02:08, 13 April 2015 (UTC)

I also agree on not considering these kind of awards. Stonecreek 03:07, 13 April 2015 (UTC)

Likewise, although for $85 I would be willing to reconsider... Albinoflea 21:02, 15 April 2015 (UTC)

New report: My Errored Out Edits

The top section of the navigation bar has been changed to let editors view a list of their errored our submissions. The report is currently empty for most editors (a good thing), but JLochhas, Hitspacebar, Linguist and Mhhutchins should be able to see their errored out submissions. In addition, the layout of some "My Recent" reports has been tweaked not to display the rightmost column if it doesn't make sense in the context of the report. Ahasuerus 02:11, 13 April 2015 (UTC)

Once resolved, is it possible to remove an item from the list? There doesn't seem to be a problem with the submission I made (I must have corrected it subsequently), but unlike the other lists, it should be removable to avoid having to determine every time you check the list whether the problem has been fixed. Maybe have an "issue resolved" link? Thanks. Mhhutchins 03:21, 13 April 2015 (UTC)

I can see how it would be useful. On the other hand, I am concerned that a naive editor may "resolve" an errored out submission and make debugging more difficult. I'll have to think about it; perhaps a compromise solution is possible. Ahasuerus 03:39, 13 April 2015 (UTC)

I'm not even sure if the report for non-moderating editors would be useful at all. Would they even know how to "fix" any problems that was caused by the errored-out submission? Perhaps I'm misunderstanding the report's purpose. Mhhutchins 04:42, 13 April 2015 (UTC)

Well, the main purpose of these reports is to tell our editors what happened to their submissions. If a submission errors out, it doesn't show up on any of the three main reports ("Pending", "Approved" or "Rejected"). Without this additional report the submitting editor would have no way of telling what happened to his errored out submissions.

In addition, this report lets editors view their errored out submissions as they existed prior to approval, which can be useful when a submission is partially approved. Ahasuerus 06:32, 13 April 2015 (UTC)

ISFDB downtime -- 7pm server time

I will be taking the site down at 7pm server (US Central) time. Everything should be back up within 5-10 minutes. Ahasuerus 23:38, 16 April 2015 (UTC)

We are back up. Ahasuerus 00:04, 17 April 2015 (UTC)

New author field - Transliterated Legal Name

The patch that will be installed at 7pm server time will add the much-discussed repeatable "Transliterated Legal Name" field to author records. It should be reasonably self-explanatory, but more detailed patch notes will be posted later tonight. Ahasuerus 23:59, 16 April 2015 (UTC)

See Alexander Bogdanov for an example of an author with two transliterated legal names. I am currently rerunning the nightly job, which will add a new cleanup report for "Non-Cyrillic Authors with Latin Legal Names". Ahasuerus 00:05, 17 April 2015 (UTC)

The nightly job has been rerun and moderators can now access the new cleanup report, "Authors with a non-Latin Working Language and a Latin Legal Name". Non-moderators can use Advanced Search to find "/"s or "("s in Legal Names and then submit edits moving transliterated values to the new field.

A few related issues have come up while working on these changes. First, it looks like some editors have been copy-and-pasting Cyrillic names from Wikipedia. It turns out that Wikipedia adds special diacritics to indicate which syllable should be emphasized, e.g. see http://en.wikipedia.org/wiki/Yevgeny_Baratynsky . We shouldn't be entering these diacritics because they mess up searches. I believe I have identified and corrected all of these problem names.

Second, it turns out that the way email addresses and Web page URLs were filed into the database had a problem. Normally, emails and URLs should not contain Unicode characters (although they are supported by Web browsers) and our software tried to enforce this restriction. However, the implementation was very poor: an edit containing an email address or a Web page URLs with embedded Unicode characters would be accepted, but the value would be silently discarded without letting either the submitting editor or the approving moderator know about it. Ugh. For now I have changed the software to accept email addresses and Web page URLs as submitted. There is another feature request to implement more intelligent URL validation at data entry time.

Third, I have discovered a problem with the way Advanced Search handles "OR" searches when multiply occurring fields like transliterated legal names, Web page URLs and Pseudonyms are involved. It's not an easy problem to fix, so I created a Bug report and left it alone for now.

Finally, please keep in mind that this is our guinea pig for implementing multiply occurring fields for transliterated values. If everything works well, we can expand it to cover Publishers, Pub Series, Titles and eventually canonical author names. Feedback is more than welcome! Ahasuerus 03:56, 17 April 2015 (UTC)

About your last statement: God, I hope not. There are editors who can barely understand how to fill out the fields of the software as it is currently. I can't imagine having to explain the use of multiple recurring fields. Mhhutchins 04:48, 17 April 2015 (UTC)

Well, a multiply occurring field is simply a field that has an "Add ..." button associated with it. We already have quite a few of them, e.g. "Add Author", "Add Artist" or "Add Web Page".

The idea behind adding a separate field for transliterated values is to simplify things rather than to complicate them. Currently, some editors enter non-Latin values using the original alphabet, some use transliterations and some use a mix. For example, consider this publisher. The Cyrillic name is "АРМАДА", but we list it as "АРМАДА (Armada)" with the Romanized form of the name appended in parentheses. Even worse, its only publication series, "Фантастический боевик", is listed as "Фантастический боевик (Fantasticheskij boevik, en. Funtastic Thriller)." [sic!]. Once the proposed "Transliterated ..." fields have been added to Publisher and Publication Series records, we will be able to move all Romanized names to these new fields and everything should look much cleaner. Ahasuerus 15:21, 17 April 2015 (UTC)

Thanks for this new, welcome field. If I understood the help notice right, does this mean that it can also be used for, say, Cyrillic or Japanese transcriptions of latin-alphabet author names ? Linguist 15:24, 17 April 2015 (UTC).

This is probably something that we will want to discuss on the Rules and Standards page in greater depth, but I can think of two types of scenarios which call for entering non-Latin names in the new field.

The first scenario covers languages which use multiple alphabets or, more generally, multiple "scripts" since not all scripts are alphabets. For example, Japanese names are usually written using kanji, but in certain cases hiragana or katakana are used. In Serbian, both Latin and Cyrillic are used. In Azerbaijani, the Perso-Arabic script, Cyrillic and Latin have all been used at different points in time (and place.)

When dealing with these cases, my preferred approach would be to enter the "primary" script of the author's working language in the Legal Name field and enter the other non-Latin forms of the legal name in the new Transliterated Legal Name field. Sometimes which script is primary is reasonably clear, e.g. in Japanese it's kanji and in Serbian it's Cyrillic. Other times it can be complicated, e.g. the primary script of the Azerbaijani language depends on whether the person lives in ex-Soviet Azerbaijan or the Azerbaijani-speaking region of Iran.

The second scenario covers people who have lived in different countries which use different alphabets/scripts. For example, Alexander Lomm was born in Russia to Czech parents who moved back to Czechoslovakia when he was still a boy. He published a number of SF works in Russian between 1959 and 1976 and then switched to Czech. We currently list Russian as his "working language", so I entered the Russian version of his legal name in the Legal Name field while relegating the Czech version and the streamlined Romanized version to the Transliterated Legal Name field.

Somewhat similarly, Pavel Amnuel, who lived in the Soviet Azerbaijan in the 1940s-1950s and wrote in Russian, emigrated to Israel in 1990 although he continues to write in Russian. I would enter the Russian version of his legal name in the Legal Name field and the Romanized/Hebrew versions in the Transliterated Legal Name field.

I can't think of any other scenarios at the moment, but perhaps I am missing something. Ahasuerus 18:00, 17 April 2015 (UTC)

(unindent) A cleanup patch has been installed. There should be no user-experienced impact except that moderators will find a few additional authors on the new cleanup report. Ahasuerus 00:50, 20 April 2015 (UTC)

Publisher's name modification

Hello. Would it be possible for a moderator to modify this publisher's name to Vértice (with an accent), which is the correct spelling ? The accent is not necessary when the word is written in capitals (as on the book covers), but should appear when it is written in lower case. TIA, Linguist 14:02, 17 April 2015 (UTC).

Done. Hauck 14:40, 17 April 2015 (UTC)

Thanks ! Linguist 15:27, 17 April 2015 (UTC).

Link to "view issue grid" for parent series missing if it has sub-series

I'm making myself familiar with series and sub-series right now and came across something odd which looks like a small site navigation bug to me: if you look at the page for the series Whispers, only the sub-series have a "View Issue Grid" link. There's no link to view the issue grid of the whole "Whispers" series and all its sub-series. However, if you go to the issue grid of one of the sub-series, e.g. to that of Supplement to Whispers, there's a link called "Sub-series of Whispers (View Issue Grid)" which leads to an issue grid of the parent series "Whispers" including all sub-series. Shouldn't that link appear on the page for the parent series as well? Hitspacebar 21:24, 26 April 2015 (UTC)

I agree that there should be a link to view the issue grid of the superseries. I'd noticed that in the past but discovered the same work-around that you did. It would be nice to have a direct link. Mhhutchins 22:11, 26 April 2015 (UTC)

The way the series display logic worked 5 (?) years ago when I added support for series grids, there was no easy way to determine whether a series which consisted of sub-series included EDITOR titles. However, I rewrote the series display logic late last year and the new algorithm may allow this determination. I'll see what I can do. Ahasuerus 22:17, 26 April 2015 (UTC)

But there is already a page, and therefore and algorithm, for the issue grid of the parent series and all its sub-series (http://www.isfdb.org/cgi-bin/seriesgrid.cgi?31508 in the example above]. Wouldn't it suffice to simply add a link to this issue grid on the parent series page? Hitspacebar 08:09, 27 April 2015 (UTC)

The grid link is only displayed if there are EDITOR (i.e. Magazine/Fanzine) titles in the series. There is no grid link on non-magazine series pages like Chronicles of Amber (Corwin) or its super-series Amber.

The trick is to determine whether there are EDITOR records in any sub-series before the logic starts displaying them. In the past it was not possible because the series display code displayed one series at a time and called itself recursively for sub-series. However, the recent rewrite added a fair amount of pre-processing, which, e.g., lets it display all tags associated with titles in sub-series -- see the Amber example. Ahasuerus 16:06, 27 April 2015 (UTC)

Looking at the superseries for Whispers, I can see why it might not work to have a link to the "issue" grid, if some of the publications aren't actually issues, i.e. they're book publications. That grid is awfully confusing, even to a veteran. I don't know what a casual user would think of it. Maybe in situations where there's a mix of EDITOR and non-EDITOR records, we shouldn't display a grid at all? Mhhutchins 17:11, 27 April 2015 (UTC)

Mixed magazine-book series have always been a thorny problem since it's a question of degree. If a series contains 1 magazine issue and 100 books, presumably we don't want a grid link to appear. But if it contains 100 magazine issues and 1 book, then we do. Where do we draw the line?.. Ahasuerus 17:40, 27 April 2015 (UTC)

(unindent) The requested change has been made. Ahasuerus 20:19, 27 April 2015 (UTC)

Server performance - 2015-04-26

I am aware of the fact that the server has been sporadically slow today. As far as I can tell, it's not something that we have any control over. If this pattern continues tomorrow morning, I will ask Al to have the hosting company bounce the server. Ahasuerus 22:38, 26 April 2015 (UTC)

Webzines

I've recently encountered a situation where a webzine submission was rejected. What's the deal with webzines? How is one to know which are acceptable and which not? Pkeets 04:46, 29 April 2015 (UTC)

As the Rules of Acquisition explain:

Works published in a web-based publication (webzine) and available only as an HTML readable file are not eligible for inclusion with the following exceptions:

It is published by a market which makes the author eligible for SFWA membership (listed here).
It has been shortlisted for a major award. (This last may include works which are self-published by an author on their own website. Otherwise such works are not eligible.)

That means that a webzine which is downloadable in any number of ebook formats (MOBI, EPUB, PDF, etc.) is eligible for the database. Of course, it goes without saying that the publication must also qualify under the definitions of speculative fiction. If you can provide a link to the webzine, I can give you a definite response as to whether it is eligible. Thanks. Mhhutchins 06:00, 29 April 2015 (UTC)

What is the list that gives webzines "of interest"? Some of these are on the pro list and some not. I believe some may have had nominations for the Nebula Award. Pkeets 12:08, 29 April 2015 (UTC)

That's a set of links to webzines which may be of interest to spec-fic readers. That's all. Being on that list doesn't mean they are eligible for inclusion in the ISFDB. (There's even a proviso stated in the header of the list.) Again, I can only help you if you can give me a specific webzine. Mhhutchins 17:10, 29 April 2015 (UTC)

Okay, Silver Blade is the one that came up. I understand they pay pro rates for poetry, but not fiction. Will that make a difference? Pkeets 18:59, 29 April 2015 (UTC)

If you're referring to this webzine, it doesn't appear to be downloadable as an ebook, so we go to the two exceptions stated in the inclusion policy. 1) It is not listed as a market for which SFWA accepts membership eligibility, and 2) it has not been shortlisted for a major award. So the webzine is not eligible for the ISFDB. Stories by authors published there can be listed and linked on the authors' bibliographic comments pages. Mhhutchins 19:38, 29 April 2015 (UTC)

Okay, thanks. Pkeets 00:40, 30 April 2015 (UTC)

Re warning messages

I have just noticed that no frantic yellow warning message appears when you combine NOVEL + ss in a submission. As forgetting to change an entry type in OMNIBUSes or ANTHOLOGIes appears to be not that uncommon, I was wondering about the relevance of such a warning — or am I the only one to make that mistake ? Linguist 13:31, 30 April 2015 (UTC).

The software allows the possibility of SHORTFICTION contents in a NOVEL-typed publication record, usually a bonus story or an excerpt. Is that what you're referring to? Mhhutchins 17:36, 30 April 2015 (UTC)

No, I mean when you create, say, an OMNIBUS, the entry type is automatically set to NOVEL. When entering a short story, I forgot to change the setting, and just added “short story” to indicate the length. I noticed the mistake when submitting the pub, but I was surprised that the discrepancy didn't trigger a warning signal. Linguist 19:23, 30 April 2015 (UTC).

I don't think such a rare occurrence warrants a warning. Most editors would see the error once they've checked the resulting record. (I may be assuming too much that editors actually check their records after they've been accepted.) I've just done an Advanced Search for NOVEL-typed records with a "ss" storylen and the results were nil. I did other searches: with a "nv" storylen and there were about 50 records returned, with a "nt" there was only one record, and with "sf" there were about 25. I'll correct all of them. It's possible that some of them are not really NOVELs but SHORTFICTION, but more likely that the storylen was the error. Thanks for bringing the possibility of NOVEL-typed records having a storylen designation. Mhhutchins 19:48, 30 April 2015 (UTC)

Sorry about the extra work :o) ! Linguist 19:56, 30 April 2015 (UTC).

Turns out that of the 80 or so records, about a dozen were actually SHORTFICTION, so corrections in the pub records had to be made. In the other cases, it was just a matter of removing the storylen designation. Mhhutchins 21:46, 30 April 2015 (UTC)

Language for synopses

Re this record: is there a stated or implied policy that text on the website be in English? Mhhutchins 20:26, 1 May 2015 (UTC)

Apart from the language policy, there might be another problem: the German synopsis is an exact copy of the synopis of the amazon.de record. Is that allowed? Isn't the synopsis copyrighted to amazon? Hitspacebar 20:36, 1 May 2015 (UTC)

It is my understanding of our language policy (posted earlier this year) that:

...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.

Ahasuerus 20:42, 1 May 2015 (UTC)

I think copying synopses from another source might be considered fair use as long as it's sourced. (They are usually generated by the publisher to be used in places like Amazon and OCLC.) There are too many editors adding these synopses without giving the source and that should be considered wrong. Mhhutchins 20:58, 1 May 2015 (UTC)

I added this rule to Template:TitleFields:Synopsis. Hope it's ok that way. Hitspacebar 08:46, 2 May 2015 (UTC)

Yes, that was OK. Having it documented makes a better case to present to new editors. Thanks. Mhhutchins 03:20, 3 May 2015 (UTC)

Larry Kramer's novel eligible for the database?

Is there anyone familiar with Larry Kramer's novel The American People: Volume 1: Search for My Heart? I'm holding a submission to add it to the database, but I can find nothing online about any speculative or fantastic element to the book. The closest thing to speculation I've found is that it purports to be a "secret history" of America, and I'm not sure to what extent that makes it eligible. We have works by Pynchon, DeLillo, and other postmodern authors which play similar games. Any advice in this regard is appreciated. Thanks. Mhhutchins 03:42, 3 May 2015 (UTC)

The publisher says:

In this magisterial novel's sweeping first volume, which runs up to the 1950s, we meet prehistoric monkeys who spread a peculiar virus, a Native American shaman whose sexual explorations mutate into occult visions, and early English settlers who live as loving same-sex couples only to fall victim to the forces of bigotry. George Washington and Alexander Hamilton revel in unexpected intimacies, and John Wilkes Booth's motives for assassinating Abraham Lincoln are thoroughly revised. In the twentieth century, the nightmare of history deepens as a religious sect conspires with eugenicists, McCarthyites, and Ivy Leaguers to exterminate homosexuals, and the AIDS virus begins to spread.

So it appears to be a rather sweeping "secret history" rather than a few tweaks here and there that historical novelists have been known to make. Ahasuerus 03:49, 3 May 2015 (UTC)

Thanks for the explanation. I'll accept the submission. Mhhutchins 06:31, 3 May 2015 (UTC)

Klepsydra by Roessner

I believe that Michaela Roessner's story "The Klepsydra" is double listed, once with a sub-title. The story was sold to the (unpublished) Polyphony 7 anthology, and later published in F&SF. I presume this is the same story, and the 2 listings should be combined. RogerSSS 04:45, 4 May 2015 (UTC)

Yes, I'm pretty certain it's the same story. I've merged the two into one record. Thanks for bringing it to our attention. Mhhutchins

Arnason hwarhath

The Eleanor Arnason story "The Woman Who Fooled Death Five Times" is definitely a hwarhath story (the subtitle is "A Hwarhath Folk Tale") and should be listed under that series. RogerSSS 15:13, 4 May 2015 (UTC)

I've done the change, but note that it may be a faster process to submit the modifications yourself. Hauck 15:43, 4 May 2015 (UTC)

Graham Joyce Partial Eclipse

Does anyone own Graham Joyce's Partial Eclipse collection from Subterranean? isfdb lists "The Mountain Eats People" in this collection, my own Joyce short fiction list does not, but I don't have the book to confirm this. Locus does list "Mountain" in Partial Eclipse, but a spot check of library websites does not. Can anyone check this? RogerSSS 02:47, 6 May 2015 (UTC)

The OCLC record doesn't mention it, but they record their contents from the content page (unlike the ISFDB that requires editors to enter contents from each work's title page.) Unlike most of their listings, the publisher's website doesn't give the complete contents. "Mountain" isn't mentioned. The ISFDB listing looks like it came from Locus, so if they're wrong (which seems likely), then our listing is wrong. I'll remove the story, and give the contents based on the OCLC listing and note that Locus adds another story. Mhhutchins 03:00, 6 May 2015 (UTC)

The Locus listing says there are ten stories, but lists eleven, so the extra story is very likely an error. Mhhutchins 03:07, 6 May 2015 (UTC)

Ben Peek's "Verflucht"

The german title "Verflucht" (German series title: "Ära der Götter") this title seems to be a variant title from this. The same character, same towns. The only uncertainty is a remark on the copyright page in my book: Titel der australischen Originalausgabe:"Immolation", Tor Books, London 2014. This title appears only here. Can someone tell me, what is right? --Wolfram.winkler 20:02, 10 May 2015 (UTC)

It's a title change, see what the author says. Hauck 21:19, 10 May 2015 (UTC)

Thanks for the info--Wolfram.winkler 07:03, 11 May 2015 (UTC)

I have varianted "Verflucht" to "The Godless" for you. Christian Stonecreek 09:19, 11 May 2015 (UTC)

You're faster than me, thanks.--Wolfram.winkler 11:28, 11 May 2015 (UTC)

Jared Diamond

I am wondering why the author Jared Diamond is on ISFDB. We have one non-fiction book work for him that was not reviewed and does not seem remotely specfict. Did I miss something or should this publication, title, and author be deleted? --Marc Kupper|talk 02:43, 16 May 2015 (UTC)

I say nuke it. Mhhutchins 03:34, 16 May 2015 (UTC)

<AOL> Ahasuerus 03:55, 16 May 2015 (UTC)

nuked</AOL> --Marc Kupper|talk 13:50, 16 May 2015 (UTC)

Broken link to help page on "Title Editor" page

The help link next to the "Graphic Format" label on the "Title Editor" page (cgi-bin/edit/edittitle.cgi) is broken. It links to the non-existing page http://www.isfdb.org/wiki/index.php?title=Template:TitleFields:Graphic but should probably link to http://www.isfdb.org/wiki/index.php?title=Template:TitleFields:GraphicFormat. Jens Hitspacebar 11:17, 16 May 2015 (UTC)

Moreover, the content of the help on http://www.isfdb.org/wiki/index.php?title=Template:TitleFields:GraphicFormat ("Titles of all types can be "graphic" except REVIEWs and INTERVIEWs.") doesn't fit the mouse hint you get when you hover over the question mark for the "Graphic Format" field ("COVERART and INTERIORART titles can't be graphic."). Hitspacebar 11:26, 16 May 2015 (UTC)

I updated Template:TitleFields:GraphicFormat to also state COVERART & INTERIORART cannot be marked as graphic. Fixing the link and updating the tooltip to include REVIEW and INTERVIEW will require a code change. Ahasuerus will likely take care of that when he sees this. -- JLaTondre (talk) 12:48, 16 May 2015 (UTC)

I would think EDITOR should also be an exception unless we plan on allowing graphic format periodical publications, i.e. comic books, into the db. Even though it might be stretching the definition, I suppose an ESSAY can be presented in a graphic format, which means a book-length nonfiction graphical work would make NONFICTION eligible for the flag as well. Mhhutchins 17:19, 16 May 2015 (UTC)

Yes, ESSAYs can be presented in a graphic format. Here's a current example I just edited: The Religious Experience of Philip K. Dick. Jens Hitspacebar 17:57, 16 May 2015 (UTC)

(unindent) Fixed. Thanks for identifying and reporting the issue! Ahasuerus 04:00, 17 May 2015 (UTC)

Messages and Replies

1. You have a new message. This takes you directly to the bottom of your talk page which is not necessarily where the 'new' message is. To find it one has to click the 'history' tab to find out what's been changed. Is there a more obvious way of finding the 'new' message or is there no way the yellow warning can take you directly there ? --Mavmaramis 02:44, 17 May 2015 (UTC)

I am afraid that our Wiki's behavior, including the way "New Messages" functions, is largely outside of our control because we use third party Wiki software. There are some things that we can customize, but they are relatively few and far between compared to the behavior of the core ISFDB application, which we are much better positioned to control.

I don't have a good answer to your specific question, but perhaps some other, more Wiki-clueful editors may provide one. Ahasuerus 04:07, 17 May 2015 (UTC)

As Ahasuerus said, there is no way to directly get to the new message(s). If it's a new topic, it should be at the bottom of the page (assuming the message leaver properly used the "+" to add a new topic). If it's not obvious from scanning the page what is new, you can use the page history. Click the "history" tab at the top the page and then click the "Compare selected revisions" button on the new page. This will show the difference between the current version and the previous version. You can also select which version you are comparing if you need to go back more than one revision. -- JLaTondre (talk) 12:02, 17 May 2015 (UTC)

Actually, there is a way to go to the page in "diff since last viewed mode". The new messages link was originally set up to do that, but it has been changed to simply bring up the talk page instead. It could be changed back. I agree with the sentiment and would prefer the diff mode behavior be restored, although there must have been some other usability issue that motivated making the change. --MartyD 18:31, 18 May 2015 (UTC)

The method is to add "?diff=cur" to the link to the page. --MartyD 18:37, 18 May 2015 (UTC)

Oh! Yes, I think I remember it now. The problem was that "?diff=cur" only shows you the last change as opposed to all the changes since you last viewed the page. I seem to recall that it led new users to believe that they had only one new message that they needed to respond to. Ahasuerus 18:43, 18 May 2015 (UTC)

I believe the change was prompted by my request. In "diff" mode you couldn't respond, and its display often confused new editors. My suggestion to have the message warning link directly to the user's talk page was just a matter of simplicity. If that's not "standard" wiki procedure, feel free to change it back. And be prepared to deal with new editors who have problems discovering their user talk page. As someone who deals with new editors more than the average moderator, I know that since the change the response to user talk pages has improved tremendously. Mhhutchins 19:09, 18 May 2015 (UTC)

2. Replies. If you ask a primary verifier a question it might be days, weeks or even months before they reply. Does this flag up as "You have a new message" ? Otherwise one would have to (a) remember to whom the message was posted, when, and topic or (b) scroll back through "my contributions" in the hopes of finding it amongst the swath of other messages which are more than likely merely notes about additions to records or image uploads. --Mavmaramis 02:44, 17 May 2015 (UTC)

An editor's response on his or her Talk page won't result in you getting a "You have a new message" notification. If you see that an editor hasn't been active in some time, it may be prudent to say something like "When you see this message and respond here, could you please also leave a note on my Talk page so that I would know to check your talk page?" Ahasuerus 04:07, 17 May 2015 (UTC)

I found out how to use the "Watchlist" function which is probably the way to go. But you're right. All came about as I was wondering how, if someone posts a question on your talk page, they know you've responded. --Mavmaramis 08:00, 17 May 2015 (UTC)

Yes, the watchlist is how the wiki is designed to track updates to pages. It's not perfect, as it shows all changes to the page, but it lets you know when you should check the page. -- JLaTondre (talk) 12:02, 17 May 2015 (UTC)

The latest version used by the English Wikipedia has a message notification system which shows you the changes and allows for linking to specific discussions. It also allows for pinging an editor (using {{ping|username}}), which notifies the editor that someone wants their attention on a specific page. That would be a useful tool here, too. Nihonjoe 16:43, 28 May 2015 (UTC)

In or Out? Fictional Biography of Sir Thomas Mallory

This title is a historical fiction approach to a biography of Sir Thomas Malory. If it were a true biography, Malory is important enough that we would include this as a non-fiction book. WorldCat lists it as a "Biography", and with the little we actually know about his life it may be the closest to a biography we can expect, but it really isn't. As a novel, it has a minimal amount of spec fic in it (primarily in repeating a few of the legends as if they true stories), but to me it doesn't qualify as a genre novel. So I currently have it entered as a non-genre novel. But of course the book isn't by someone who is a spec fic author, so we would not normally include such books in here. So: (1) Does this book belong in? (2) If so, should it be listed as a non-genre novel, as I did? (See the title rec Synopsis for some additional description of the book.) Chavey 00:34, 19 May 2015 (UTC)

Disregarding the subject of the "biography", if you've determined that it's not speculative fiction, why should there be a record for it at all? Unless you believe that the author, someone I've never heard of, is "above the threshold", a non-genre novel by a non-genre author is obviously not eligible for the database. Mhhutchins 02:21, 19 May 2015 (UTC)

It looks like there are two issues here. First, even if this was a non-fiction biography, would we want to include it? What about Lucian of Samosata or Homer? Second, fictionalized biographies and, more generically, fiction about SF writers appear to be a gray area. Would a non-SF novel about Jules Verne or H. G. Wells be "in"? Ahasuerus 02:40, 19 May 2015 (UTC)

Out, there's already too much clutter. Hauck 05:49, 19 May 2015 (UTC)

ISFDB:Policy has "Speculative fiction is defined to exclude / ... works set in a future indistinguishable from the present". I'm wondering if we should add a bullet with "Works set in a period indistinguishable from factual narratives of that period. For example, works set in the U.S. Civil War era would be excluded unless they were alternate histories. Related to this is that works where the author uses country or region names not found on maps, but is otherwise indistinguishable from factual narratives, would also be excluded." --Marc Kupper|talk 21:48, 24 May 2015 (UTC)

The reason why the clause about "a future indistinguishable from the present" was added was to exclude techno-thrillers. At the time it was felt that a techno-thriller set in the year N+2 where "N=present" was not "really SF".

I assume that the second proposed clause covers Ruritarian fiction, right? What types of books do you mean to cover by the first clause? Ahasuerus 06:25, 25 May 2015 (UTC)

Six authors with murky legal names

We have 6 authors whose transliterated legal names are known while the original versions are unknown. The authors and their respective working languages are as follows:

Somadeva Bhatta - Sanskrit.
- Done (सोमदेव भट्ट); he seems to be mainly known as Sōmadēva, though. I have also modified the ṭ of the first transcription, which appeared (according to by browser anyway) as t + square. Linguist 13:40, 28 May 2015 (UTC).
Asakura Hisashi - Japanese.
- I suppose this should be 禅師大谷, Zenji Ōtani, but I just can't find an occurrence of it (which is not a good sign…). Better wait for confirmation (or not) from a native speaker. Linguist 14:39, 28 May 2015 (UTC).
Rokeya Sakhawat Hossain - Bengali
- Solved via the Bengali Wikipedia.--Dirk P Broer 16:24, 29 May 2015 (UTC)
Xia Jia - Chinese
- solved via www.renditions.org.--Dirk P Broer 16:27, 29 May 2015 (UTC)
La La - Chinese
- Solved via www.renditions.org.--Dirk P Broer 16:29, 29 May 2015 (UTC)
Swapanburo - Bengali
- My browser can't cope with this, but the answer seems to be there (legal name followed by pseudo between brackets).
  - Got it, thanks! Ahasuerus 15:18, 30 May 2015 (UTC)

If anyone happens to know the original forms of their legal names, please update the record(s). TIA! Ahasuerus 02:02, 28 May 2015 (UTC)

How about the original form of their canonical name? In the case of La La, it's 拉拉. If we ever get support for credits published in another alphabet, isn't it more important to have their canonical name than their legal name? Especially so in cases like La La who publishes only under that credit, at least according to SFE3. I believe the effort being made to establish the original form of an author's legal name isn't necessary when that's not how their work is actually published. Mhhutchins 04:29, 28 May 2015 (UTC)

I certainly agree that canonical names are more important than legal names, but that's exactly why I started with the legal name field as a test case/guinea pig. I figured that since it was less important, any problems/bugs introduced during the implementation process wouldn't have as much of an impact and, besides, we would likely learn useful lessons. And that's exactly what happened -- there was a minor bug that I still need to fix and I have identified two enhancements that need to be coded :-) Ahasuerus 16:11, 28 May 2015 (UTC)

Asakura's real name is 大谷善次 (Ōtani Zenji), not 禅師大谷 (which is in the wrong order (should be 大谷禅師), and has two incorrect characters in it). The kanji for his pseudonym are 浅倉久志 (Asakura Hisashi), just in case we ever have a way to enter those, too. He was also sometimes called 大浅倉 (Ōasakura). I updated the author page for him. Hope that helps. Nihonjoe 16:32, 28 May 2015 (UTC)

Approved, thanks! Ahasuerus 17:07, 28 May 2015 (UTC)

According to the Japanese Wikipedia he also uses numerous other pseudonyms as well (apparently the publisher thought it did not look good to have everything translated by a single person) such as: 深谷節 (Setsu Fukaya), 沢ゆり子 (Yuriko Sawa), 牟礼一郎 (Ichirō Mure), and 大谷圭二 (Keiji Ōtani). I find it interesting the first two of those are normally considered to be female names. The last one also seems to have its own authority entries (see http://viaf.org/viaf/251386820/). Uzume 14:53, 30 May 2015 (UTC)

Maren and Sanjulian

Today is the birthday of an artist named Maren, pseudonym of Mariano Pérez Clemente Sanjulián. His book covers bear a similarity to the style of Sanjulian, whose full name is Manuel Pérez Clemente Sanjulián. Both share the same middle and last names and the birthplace of Barcelona, Spain. Could they be brothers? RR 06:14, 3 June 2015 (UTC)

According to this, yes. ···日本穣 · 投稿 · Talk to Nihonjoe 22:26, 3 June 2015 (UTC)

Two series with the same title

Just yesterday, I submitted four books by Fuyumi Ono, all of which are in a series called The Twelve Kingdoms. When I went to look at it just now, another set of unrelated books by Jeffe Kennedy are now listed as part of the series, too (they weren't there before, as far as I could tell). What is the naming protocol for differentiating between them? Add a "(I)" after the new series title? ···日本穣 · 投稿 · Talk to Nihonjoe 22:02, 3 June 2015 (UTC)

It looks like it might have to do with my adding a parent series which may have already existed. We need to pull out the Fuyumi Ono books and put them in their own Twelve Kingdoms series, and then have that series be in a separate Twelve Kingdoms Universe. ···日本穣 · 投稿 · Talk to Nihonjoe 22:13, 3 June 2015 (UTC)

One possibility is to use the Japanese title as part of it by making it "Jūni Kokuki: The Twelve Kingdoms". ···日本穣 · 投稿 · Talk to Nihonjoe 22:23, 3 June 2015 (UTC)

And, I'll be happy to do all the work, at least the work on this side of moderation. Should the parent series have the same name? ···日本穣 · 投稿 · Talk to Nihonjoe 22:44, 3 June 2015 (UTC)

Unfortunately, "series collision" is a common problem. If you do a series search on "The Guardians", you'll find:

As you can see, they are usually disambiguated using the author's name. However, in this case it looks like it would be better to use the original series name in conjunction with the translated name the way ログ・ホライズン / Log Horizon (light novels) and Лабиринты Эхо / The Labyrinths of Echo were done. I should also add that there is no "variant series name" mechanism, so multiple names are simply concatenated using slashes, e.g. Opal Cowan / Glass / The Chronicles of Ixia. Ahasuerus 23:43, 3 June 2015 (UTC)

Okay, I've updated the title name on the Ono books. Once those are approved, I'll modify the name of the Kennedy series. ···日本穣 · 投稿 · Talk to Nihonjoe 23:55, 3 June 2015 (UTC)

Approved, thanks. Ahasuerus 00:18, 4 June 2015 (UTC)

Okay, I've updated the series info now. Once those are approved, I'll move the Ono series back into the correct parent series. ···日本穣 · 投稿 · Talk to Nihonjoe 00:33, 4 June 2015 (UTC)

Approved. Ahasuerus 01:46, 4 June 2015 (UTC)

And the parent series has been added now. Thanks for all your help. ···日本穣 · 投稿 · Talk to Nihonjoe 03:31, 4 June 2015 (UTC)

Looks good, thanks! Ahasuerus 03:36, 4 June 2015 (UTC)

(unindent) On a different note, but related to this discussion, the English publications (three of them) actually combined volumes from the Japanese, so volume 1 part 1 and part 2 in Japanese were combined into one volume in English. How do I indicate their place within the series since there isn't a way to do a 0.5 (at least for the first volume)? Do I need to create another mini series for each of the two-part Japanese volumes, and then add them that way, so they can be in the right place within the main series? I hope that makes sense. If not, I can make a longer post explaining things in more detail. ···日本穣 · 投稿 · Talk to Nihonjoe 03:38, 4 June 2015 (UTC)

I am not entirely sure I am following, so let me first ask whether this Wikipedia listing is accurate? Ahasuerus 21:12, 5 June 2015 (UTC)

Yeah, I was worried my explanation was too convoluted. Let me try again. This Wikipedia page lists them like this (which is correct). This is the main series:

0. The Demonic Child (魔性の子) (1991-09-25, Shinchosha, ISBN 4-10-124021-3, only loosely related due to parts of it which Ono tied into the main series)

1a. Shadow of the Moon, Sea of Shadow (part 1) (月の影影の海（上）) (1992-06-20, Kodansha, ISBN 4-06-255071-7)

1b. Shadow of the Moon, Sea of Shadow (part 2) (月の影影の海（下）) (1992-07-20, Kodansha, ISBN 4-06-255072-5)

2a. Sea of Wind, Shore of the Labyrinth (part 1) (風の海迷宮の岸（上）) (1993-03-20, Kodansha, ISBN 4-06-255114-4)

2b. Sea of Wind, Shore of the Labyrinth (part 2) (風の海迷宮の岸（下）) (1993-03-20, Kodansha, ISBN 4-06-255120-9)

3 Sea God in the East, Vast Sea in the West (東の海神西の滄海) (1994-06-05, Kodansha, ISBN 4-06-255168-3)

4a. A Thousand Miles of Wind, The Sky at Dawn (part 1) (風の万里黎明の空（上）) (1994-08-05, Kodansha, ISBN 4-06-255175-6)

4b. A Thousand Miles of Wind, The Sky at Dawn (part 2) (風の万里黎明の空（下）) (1994-09-05, Kodansha, ISBN 4-06-255178-0)

5 The Aspiring Wings (図南の翼) (1996-02-05, Kodansha, ISBN 4-06-255229-9)

6a. The Shore at Twilight, The Sky at Daybreak (part 1) (黄昏の岸暁の天（上）) (2001-05-15, Kodansha, ISBN 4-06-255546-8)

6b. The Shore at Twilight, The Sky at Daybreak (part 2) (黄昏の岸暁の天（下）) （2001-05-15, Kodansha, ISBN 4-06-255550-6)

7. The Dream of Prosperity (華胥の幽夢) (2001-09-05, Kodansha, ISBN 4-06-255573-5, collection of 5 short stories)

8. The Birds of Hisho (丕緒の鳥) (2013-07-01, Shinchosha, ISBN 978-4-10-1240589, collection of four short stories)

In the States, Tokyopop published English translations of 1a and 1b together in one volume as Sea of Shadow, 2a and 2b together in one volume as Sea of Wind, and 4a and 4b together in one volume as Skies of Dawn. I'm trying to figure out how to number the "a" and "b" parts so they correspond with the English volume 1. Do I need to make a separate series just for the Japanese releases? I hope that makes more sense. Thanks. ···日本穣 · 投稿 · Talk to Nihonjoe 21:47, 5 June 2015 (UTC)

Thanks, I think I got it now. What I would do first is enter the original Japanese books, ISBNs and all. I would then add them to this series. The series numbers could be either 1-12 or "1.1, 1.2, 2.1, 2.2, 3, 4.1, 4.2, 5, 6.1, 6.2, 7, 8" depending on what seems more appropriate. Finally, I would convert the English translations to omnibuses so that they would appear at the end of the list -- see this listing for an example. Alternatively, you could create a separate sub-series for the omnibuses the way the last three sub-series in this series are done. Does this make sense? Ahasuerus 22:16, 5 June 2015 (UTC)

Yes, perfect. Thanks. I'll work on that. ···日本穣 · 投稿 · Talk to Nihonjoe 00:02, 6 June 2015 (UTC)

Okay, they've been added. ···日本穣 · 投稿 · Talk to Nihonjoe 18:05, 6 June 2015 (UTC)

Archives and header info template

If you look at the top of the page, you can see a new archives template which makes it easy to go back to a specific page directly, without having to go to the full archive listing. I hope it makes things easier. ···日本穣 · 投稿 · Talk to Nihonjoe 04:13, 4 June 2015 (UTC)

I also made one for each archive page to ease navigation and give easy access to the main archive page (see here for an example). The only one I couldn't edit was ISFDB:Community Portal/Archive/Archive09, because the page is apparently locked. If someone will add {{Isfdb-comm-portal-archives}} to the top of that one, then all of the archives will have the navigation. ···日本穣 · 投稿 · Talk to Nihonjoe 04:52, 4 June 2015 (UTC)

To give more details, I made the following templates:

{{Isfdb-comm-portal-header}} (link) - This one contains the general information links at the top of this page, and also transcludes {{Isfdb-comm-portal-archives}} to give the archive links.
{{Isfdb-comm-portal-archives}} (link) - This one is the tan archive link box at the top right of this page.
{{Isfdb-comm-portal-archive-header}} (link) - This one is used on the top of indivdual archive pages, and has an archive specific notice and transcludes {{Isfdb-comm-portal-archives}} to give access to all the archive links from every archive page.

Hope that makes sense. ···日本穣 · 投稿 · Talk to Nihonjoe 05:17, 4 June 2015 (UTC)

I also made Template:Development-resources which is at the top of the Development page, Template:Moderator-availability which is at the top of ISFDB:Moderator noticeboard, and Template:Isfdb-general-header which is at the top of all the pages listed in it (you can see it at the top of this page). ···日本穣 · 投稿 · Talk to Nihonjoe 17:55, 4 June 2015 (UTC)

Translations not shown on author page when not logged in

You only see the parent titles and English variants on the Summary Bibliography of an author, but apart from that no other translations if you're not logged in. Why is that? I think it'd be much better if anonymous users could see all data. Jens Hitspacebar 08:22, 8 June 2015 (UTC)

That's right. As it says at the top of the Summary page, "Showing English translations only. Logged in users can choose which translations are shown." The idea (much debated a few years ago) was that displaying all translations could make Summary pages unwieldy, e.g. see Robert A. Heinlein's page. A logged in user can choose (under My Language preferences) which languages he is interested in. Ahasuerus 16:19, 8 June 2015 (UTC)

Ok. If it has been much debated back then and this was the outcome I will not open a new discussion about it. Though I think the way it works now is not user-friendly for people who want to browse for translations but don't want to register. Hitspacebar 18:10, 8 June 2015 (UTC)

Well, nothing is ever "absolutely positively 100% final" :-) The original discussion took place before the software was modified to support translated titles, so it concentrated on what we suspected might happen. Now that we have a fair number of translations on file, we can review the results and decide whether the current system does a good job of addressing the original concerns and whether new concerns may have arisen. Ahasuerus 19:02, 8 June 2015 (UTC)

Good :) Then I'd like to raise that topic again. As I said above, I think it's not user-friendly if someone has to register first just to see all data (imagine you had to do that at the Wikipedia just to see the links to the translations of an article). Moreover I believe that some people who are looking for non-English titles and who only take a brief first look at the ISFDB may come to the wrong conclusion that it's about English SF only and leave the site permanently.

So far I've found the following pages which are affected by this:

* Author's "Summary Bibliography"

* Series' "Series Bibliography"

Probable solutions (which apply to anonymous users only):

Solution 1: Don't filter anything and always show all variant titles. Don't offer a language filter.

Solution 2: Offer a simple checkbox "Only show titles in the author's working language", which is not selected by default and results in all languages being displayed. If selected it would show only parent and variant titles of the author's language plus the parent titles of the variant titles. The chosen value would be stored in a cookie. This might get tricky or look messy on the Series' "Series Bibliography" page if a title of a series has multiple authors with different working languages.

Solution 3: Offer the same language options that are available for registered users but store the selected values in a cookie. By default, all languages would be selected. Show a hint like "Data filtered by your language settings" if the language filter is active.

Jens Hitspacebar 10:12, 9 June 2015 (UTC)

Solution 4: Pass the wanted languages as parameter to the webpage. This way e.g. German wikipedia articles can pass "de" to show the original language and German variants. I once provided a patch for this. --Stoecker 16:33, 9 June 2015 (UTC)

(For those who were not around at the time, there is a lengthy discussion of that patch here.) Ahasuerus 17:07, 10 June 2015 (UTC)

And 1.5 years later my statement is proven: You wont be able to process the stuff I did/do the way you do it. You copied some small style gimmicks, but not a single bit of the important stuff and I did not even start something real important like translation of the UI or something alike. The SQL interface is still easy to penetrate for attacks, still no UTF-8 support, no translators support and so on. That's sad, because I still like the idea of ISFDB, but development seems a one-man-show ATM if I look at CVS changes. The fact that ISFDB sticks to an old server instead of updating to modern hardware tells me the same. But that's old news. --Stoecker 08:09, 10 June 2015 (UTC)

If you are aware of specific SQL injection vulnerabilities that still exist after the last round of fixes, please let me know via e-mail. As far as everything else goes, the reasons why we chose to stick with the current approach to development rather than use your approach are outlined in the discussion linked above. Ahasuerus 16:41, 10 June 2015 (UTC)

A few thoughts. I don't think "Only show titles in the author's working language" would work since some authors use 2+ languages, e.g. Sam Lundwall. "Only show variant titles in the author's working language" may work, but, as Jens pointed out, it may result in odd behavior on Series pages. Ahasuerus 17:07, 10 June 2015 (UTC)

I said "original language". --Stoecker 08:09, 10 June 2015 (UTC)

Understood. The quote above was from Jens's "solution 2". Ahasuerus 17:07, 10 June 2015 (UTC)

Simply display any non-varianted title, any variants with the same language as the original and also all variants with the desired additional language. That's very easy to implement (add a parameter to the webpage and remove the hardcoded English stuff). As far as I remember that was also they way I implemented it. Actually that also could be default, so ISFDB is no longer so English centric. For the English authors there would be no difference, for foreign language authors their main language would be presented in favour of English. You rejected this change last time although it was not coupled to anything else in the larger patches. --Stoecker 08:09, 10 June 2015 (UTC)

As I recall, I didn't consciously reject this particular change. The submitted patch contained literally hundreds of changes without associated bug reports or feature requests. I tried isolating and implementing individual changes one at a time, but it quickly became untenable as you continued enhancing and debugging the mega-patch. As discussed above, eventually we decided to continue using the current approach to development, so the mega-patch was set aside. Ahasuerus 17:07, 10 June 2015 (UTC)

No. You rejected specifically that patch telling me that I don't understand the software structure and that user prefs have that feature. --Stoecker 20:29, 12 June 2015 (UTC)

As I said, I don't recall consciously rejecting this particular change. If I did, then we need to review the specific objection that I raised at the time in order to see if it had merit. It's certainly possible that I misunderstood what was being proposed. Ahasuerus 23:22, 12 June 2015 (UTC)

Then you now have to change to simply apply the patch even without an UI, as in the current form it would at least allow proper links. --Stoecker 17:47, 14 June 2015 (UTC)

I am not sure I understand what you are saying here. As I said above, if you believe that, back in 2013, I explicitly rejected the change that you are now proposing, then "we need to review the specific objection that I raised at the time in order to see if it had merit". Do you have the actual wording of my objection? Ahasuerus 19:09, 14 June 2015 (UTC)

Anyway to prove my point I updated the patch and made it available again at http://isfdb.stoecker.eu/patches/01_ea_select_language.patch, The result can be seen here: http://isfdb.stoecker.eu/cgi-bin/ea.cgi?id=51&lang=German,Dutch or http://isfdb.stoecker.eu/cgi-bin/ea.cgi?id=51&lang=ALL No user interface, only the basic functionality. As UI I did suggest to add a dropdown list presenting the language names and "ALL" for everything. Code is downwards compatible, so old style still works. --Stoecker 20:29, 12 June 2015 (UTC)

P.S. With English centric I mean stuff like this in biblio/common.py which can simply be dropped without negative effects except that English is no longer preferred for originally non-English authors. That even may make the situation more obvious, as English users than have the same issue as I have with German ATM:

       for variant in variants:
               lang_filter = 0
               # Always display VTs in English
               if variant[TITLE_LANGUAGE] == 17:
                       lang_filter = 1
               # Always display VTs with no language (since 99% of them are in English)
               elif variant[TITLE_LANGUAGE] == None:
                       lang_filter = 1

--Stoecker 21:04, 12 June 2015 (UTC)

Back to the issue at hand, as you said, adding an optional parameter that would specify the desired language would be easy to implement. However, I am not sure I understand what you mean by "that also could be default". Ahasuerus 17:07, 10 June 2015 (UTC)

The use of cookies to store unregistered users' preferences is an interesting idea. I'll have to think about the implications.

Another solution would be to add a "view all languages" link to Summary/Series pages. It would be similar to the current "view Concise Listing" link on Publication pages, e.g. see this page. Ahasuerus 21:12, 9 June 2015 (UTC)

Both the "view all languages" and Stoecker's language parameter solution are ok for me, but for returning anonymous users a solution might be better where the setting survives across browser sessions so that they'll immediately be using same language they had chosen in a previous browser session each time they start the browser. Jens Hitspacebar 08:51, 10 June 2015 (UTC)

Cookies may be nice, but they don't allow setting links. As long as It is impossible to set a link to ISFDB authors which actually shows the relevant info entries ISFDB is of limited use for non-English languages. E.g. http://de.wikipedia.org/wiki/Eric_Frank_Russell has a link to ISFDB, but when the user clicks on the link he sees nearly nothing from what the page talks about. Useless. I nevertheless added the stuff in the hope that one day it will be possible to see the relevant information. Using a cookie to remember user settings is an additional nice gimmick. --Stoecker 16:47, 10 June 2015 (UTC)

Works by Person A, but retold by Person B

I have a book containing a fair number of fairy tales and other fantastical bedtime stories. Some of them list the author as "by Person A, retold by Person B". Do I list both as authors? Only the original? Only the reteller? Thanks for any help. ···日本穣 · 投稿 · Talk to Nihonjoe 05:31, 9 June 2015 (UTC)

I decided to list both authors, since the second author is basing their telling of the story on the first one. ···日本穣 · 投稿 · Talk to Nihonjoe 05:47, 9 June 2015 (UTC)

I'd do it the same way. Stonecreek 06:17, 9 June 2015 (UTC)

Glad I'm on the right page, then. :) ···日本穣 · 投稿 · Talk to Nihonjoe 18:07, 9 June 2015 (UTC)

Better way to find varianted or similar cover art

I did a bit cover similarity finding recently for the fun of it and it's a lot of useless work. Is there a better way than to load and check each cover title from an author?

If not, I'd like to expand the "Check for Duplicate Titles" to show covers for compare. Would a patch be accepted? --Stoecker 16:36, 9 June 2015 (UTC)

First we'll need to create a new Feature Request outlining the desired functionality, so let's discuss how the software behaves at this time and what the proposed changes are.

Currently the author-specific version of the Duplicate Finder displays a list of identical/similar titles, including COVERART titles. For example here is one for Leo Dillon. As you can see, it displays Notes data, which helps determine whether two or more identically named COVERART titles are known to represent different artwork. Once you select 2+ COVERART titles and click on "Merge Selected Records", you get to see all of the affected cover scans.

Are you suggesting that the cover scans for all displayed COVERART titles should be displayed on the first Duplicate Finder page? If so, then my first concern would be that it could make the page very long and very busy. Ahasuerus 20:37, 9 June 2015 (UTC)

(later edit) Perhaps we could add an option to redisplay the Duplicate Finder page with all the COVERART images shown, similar to the "view Concise Listing" link on Publication pages? Ahasuerus 00:47, 10 June 2015 (UTC)

I'd probably be better off waiting for Stoecker to clarify, but at the risk of complicating things... From the section title, I assume the request is to identify matching artwork that does not have the same publication title. The current duplicate finder only lists items with same (or similar) names. I've toyed with the idea of image comparison before, but have never tried it. I've assumed it wouldn't be that effective given different titles, blurbs, etc. not to mention image tweaks. I also assume it wouldn't be something for the production server as it would probably be resource intensive. But perhaps I will try to play around with it vs. just assume.

I have created a script that displays all the artwork for an artist on a single page. It works okay for an artist with not that many records, but isn't really workable (both in terms of browser performance and also in terms of being able to scroll through and recognize matching covers - just too many images to wade through) for the more prolific artists. -- JLaTondre (talk) 21:30, 9 June 2015 (UTC)

Oh, I see. Well, that's a different and significantly more complicated issue. For locally stored images, we could use something like pyssim, which computes the Structural Similarity Image Metric (SSIM) of two or more images. I am not sure how well it works if you feed it differently-titled/blurbed images, but it may be worth a shot. For remotely-stored images (Amazon etc), we may need to download them first, which raises a number of other issues. Ahasuerus 00:44, 10 June 2015 (UTC)

I'll setup my own server again and implement it there. --Stoecker 08:11, 10 June 2015 (UTC)

I am not sure whether your plan is to run the software that you plan to develop on a separate server. If you would like to have the new software installed on the main server, we will need a feature request and a detailed description of how it will work first. Then we can decide whether it's desirable/feasible. Ahasuerus 19:10, 10 June 2015 (UTC)

Wouldn't an action named "View all covers for this author" on the author page which simply shows all cover art of an author on a single page help already (the same way the "View all covers for ..." link on the title page does it for a title already)? That way you could do a manual comparison of the cover images visually. Jens Hitspacebar 08:35, 10 June 2015 (UTC)

I haven't experimented with this approach, but won't it cause the same problem that JLaTondre reported earlier:

It works okay for an artist with not that many records, but isn't really workable (both in terms of browser performance and also in terms of being able to scroll through and recognize matching covers - just too many images to wade through) for the more prolific artists.

? Ahasuerus 17:30, 10 June 2015 (UTC)

Oh, right, it seems like I didn't see that this approach had aleady been mentioned above. However, I'm actually not sure if performance is really such a big problem except for the few real extreme cases like Johnny Bruck or Karel Thole which have more than a thousand cover images: the page might take some time to load, but then, as long as you keep that page open once it's been loaded, you can scroll up and down to compare the images visually, and you should then definitely use separate browser tabs or windows to view image record details. Another approach to speed up performance could be server-side pagination, limiting the images to, say, 20 or maybe rather 50 images per page, which on the other hand would have the obvious and big disadvantage that you wouldn't have all images on one page for visual comparison. Jens Hitspacebar 21:36, 10 June 2015 (UTC)

(unindent)I implemented a solution which does what I want. If someone want to test it: http://isfdb.stoecker.eu with login test password test. Go to any cover artist and click on check duplicates function. Patch is here: http://isfdb.stoecker.eu/patches/02_covercompare.patch --Stoecker 00:11, 13 June 2015 (UTC)

I see that you have added 3 additional modes -- "Normal", "Single", and "Dual". However, I am not sure what each one does or how they can be used to merge duplicate COVERART titles. Ahasuerus 01:43, 13 June 2015 (UTC)

Why not simply look at it, as I gave an example installation for test above? It's pretty obvious and self-explaining. Normal = Display all different covers grouped (needs up/down scrolling to find similar entries), allows also to find mismatching groups (same name, but different picture). Single only shows one pic from each group (assuming pics are properly grouped and equal). Dual shows two columns in single mode to compare side-by-side. That's the most helpful to find variant covers. --Stoecker 10:27, 13 June 2015 (UTC)

I looked at it before your explanation and it wasn't clear to me. I was able to puzzle it out, but a production version would need more explanation for the average user. New users tend to struggle with the site. We should try to make it easier for them. I would recommend separating it from the duplicate title page (create a separate duplicate covers page) and only implementing the 'normal' and 'dual' (that was a nice idea for making it easier to compare many titles by the way) modes. The normal mode can also be used to find covers that shouldn't be merged together. Both cases need a way to select the records and merge (in the case of normal, also unmerge). They should also display the covers in alphabetical order (by title). That would have grouped a couple of duplicate records right next too each other. -- JLaTondre (talk) 12:32, 13 June 2015 (UTC)

Currently it's sorted by year. I don't think alphabetic sorting is better, as alphabetical issues can be found easy by other searches (i.e. simply looking at the tile list). For finding reuses of older covers it's better when one only needs to search in one direction. About a final implementation - That's not my topic. I implement what I need and don't care about ISFDB, as I have no positive experience there and wont try that again. --Stoecker 14:14, 13 June 2015 (UTC)

OK, thanks for clarifying. Ahasuerus 18:01, 13 June 2015 (UTC)

Looking at Stoecker's example, I did find some duplicates for Darrell K. Sweet. However, these particular ones could have also been found with an improvement to the duplicate title detection. They were of the form:

Cover: Title
Cover: Title: Subtitle

I would recommend upgrading the duplicate title detection for this case. -- JLaTondre (talk) 12:32, 13 June 2015 (UTC)

I submitted a dozen updates for making variant titles using this implementation since yesterday for 3 or 4 artists. --Stoecker 14:14, 13 June 2015 (UTC)

I case someone else want to use it - I added a third patch to my ISFDB Instance (http://isfdb.stoecker.eu/): Primary Cover patch - which shows cover information in own primary verification list and also status whether image is uploaded at ISFDB or not. I also modified the dup-finder, so that clicking on an image brings you to ISFDB. Helped me a lot to find many duplicate cover arts. Everybody feel free to use it. I'll try to update my DB with the weekly DB dumps. At least until main ISFDB has a similar functionality or uses my patches.

You can login to my instance with your normal ISFDB username and "test" as password and should find your verifications. Only remember, that submitting any changes there is useless :-) --Stoecker 12:21, 21 June 2015 (UTC)

Lem's Kongres futurologiczny / The Futurological Congress: NOVEL or SHORTFICTION?

I estimated the word count for the German edition at somewhere between 30,000 and 35,000 words (and this edition most certainly isn't abridged), which would make this rather a NOVELLA. Are there any other estimates or comments? Stonecreek 20:23, 10 June 2015 (UTC)

The Dutch and English translations are both a little over 40,000 words, estimated of course. Barely a novel, but I wouldn't change it to novella. --Willem 06:04, 11 June 2015 (UTC)

Thanks, Willem! I'll leave it as a NOVEL. Stonecreek 05:04, 13 June 2015 (UTC)

Omnibus of Hell

I try to get pub 519681 right.

Two issues:

Entry 2 is a collection of two stories. The link now goes to the collection. Should I add the stories also or is the collection link enough. I'd prefer to add the stories AND leave the link.--Stoecker 17:38, 14 June 2015 (UTC)
Entry 5 is a collection in original, but this is released as a novel. The original would be title 1277371. When I link to the title with NOVEL to COLLECTION and I know that moderators will complain. What else can I do? --Stoecker 17:38, 14 June 2015 (UTC)

I think it looks good now. There's sometimes the difficulty that an original COLLECTION is published as a NOVEL (or uncategorized without mentioning the respective shortfiction titles). It's best to cling to the original title type and add a note to the tranlated title. Stonecreek 04:04, 15 June 2015 (UTC)

Urania

When looking for covers I found this:

Verified pub 298729 is the same as unverified pub 394536, but the series links of the later seem more useful to me or maybe contents of series 25958 probably should be part of series 4934. --Stoecker 20:54, 14 June 2015 (UTC)

Cover art identification

I used to own a copy of this album by ex. Shadows and theme tune composer Brian Bennett. It was recorded in 1978 on the DJM label and subtitled "A Journey into Discoid Funk" which started life as a Bruton Music library album called "Discovery". It includes Francis Monkman of Curved Air and Sky on keyboards. Artwork looks very like Bob Layzell but the rear cover says (at blurry magnification) something along the lines of "Tony Simpson" but I'd love to find out for sure. --Mavmaramis 17:16, 20 June 2015 (UTC)

There's a line for "Sleeve Design: Roy Simpson's Ltd." It doesn't specifically mention the artist by name as far as I can see. ···日本穣 · 投稿 · Talk to Nihonjoe 23:25, 20 June 2015 (UTC)

I had it confirmed that by the man himself that it's by Bob Layzell. Great piece of art. --Mavmaramis 07:50, 21 June 2015 (UTC)

Same publication record shown twice in bibliography

This artwork is used as COVERART for the publication Exodus #31 and also appears in the same publication as INTERIORART, accompanying an essay. I varianted the INTERIORART to the COVERART to reflect that they are the same piece of art. But now the publication appears twice on the bibliography page of the artwork, which looks pretty odd. Bug? Jens Hitspacebar 14:07, 21 June 2015 (UTC)

It's quite logical given our structure. The artwork is really present twice in the publication. I personally do not enter an interior art piece that is also the cover. Hauck 14:48, 21 June 2015 (UTC)

Hm, I can't imagine any reason why it would make sense to display the same record more than once on the bibliography page, regardless the logic/database structure. Hitspacebar 08:11, 22 June 2015 (UTC)

It may be the same work, but it's not the same record. As you noted, the work appears twice in the publication so it should be displayed as two different content records. If you don't want each appearance to be displayed, just remove it from the publication record and delete the title record. Mhhutchins 13:22, 22 June 2015 (UTC)

You're right, the user should be informed about what's going on there, but that doesn't necessarily mean that two different content records must be displayed. Imagine you're an occasional ISFDB user, not an experienced editor, and you look at the record: it lists Exodus, #31 two times, both entries are the same record (same ID), and I bet almost every occasional user would except that these are two different publications. So if he doesn't examine the URL of the "Exodus, #31" links closely he might be confused if he ends up on the same record when clicking on both "Exodus, #31" links. Why should such a user come to the conclusion that that's because of two records in that publication being the same work? The conclusion that it's a software bug or just rubbish data is also a valid one if you don't examine the data close enough. However, a much more self-explanatory page would show "Exodus, #31" only once, display something like an asterisk next to it's title and print a legend stating that the asterisk means "The work appears multiple times in this publication". Jens Hitspacebar 17:00, 22 June 2015 (UTC)

Note that, at publication level (where an occasional ISFDB user may finally land), everything is perfectly clear without any "doubling" effect. Hauck 17:19, 22 June 2015 (UTC)

Hauck makes a good point. Title record display isn't the same as publication record display. Look at any title record and you'll see ALL of the publications in which that title appears. If that title happens to appear twice in a single publication, isn't it logical to display the publication twice? This happens more often with art records, but it can happen with fiction titles as well. For example, when a work appears twice in a single publication, one being a translation to a different language. The title record would display the publication twice. (Look at this title and see how the 1931 Nonesuch Press edition is displayed twice.) I understand your point about how it may confuse some users, but a few clicks should resolve the confusion. Changing the software to handle it differently seems to be more effort than such a relatively rare situation should require. But if our sole programmer believes it can be fixed quickly without creating other "bugs" then he might consider doing so. Mhhutchins 17:34, 22 June 2015 (UTC)

Yes, if it's too much effort to fix it for a few rare cases it should stay as it is (for the time being :) ). As for your question if it's logical to display the publication twice: I generally don't think it's logical at all in any application to display the same record more than once if the application doesn't provide a self-explanatory context for that. The record should always be displayed once only and the application should provide explanatory metadata about (the cause of) the multiple relationships: a simple record count or whatever fits as suitable information to explain what's going on. Displaying the same record more than once is ok however if you have nested tables where the same record can appear in different subtables (because you have a semantic context then). But I'm drifting off into general thoughts now. I understand now why it's working the way it does now. Thanks for all the feedback. Jens Hitspacebar 18:28, 22 June 2015 (UTC)

There's really no benefit from doing so, it's rather confusing. I seems to me that this is such a rare case that the software is not yet able to deal with it. Jens Hitspacebar 08:11, 22 June 2015 (UTC)

But, Jens, it seems quite logical to me, and I'd think it shouldn't be any other way. If you record an item two times it should be counted two times. It'd be possible to suppress any doubled record for a given publication, but if we'd do that, doubtless there would be inquiries why it doesn't show up a second time. Christian Stonecreek 08:57, 22 June 2015 (UTC)

Not to mention the fact that these are differently typed records and are clearly displayed as such: one is a COVERART record and the other is an INTERIORART record. I'm not sure how we remove the publication for one and not affect the other. Mhhutchins 17:37, 22 June 2015 (UTC)

See answer to Michael above. Hitspacebar 17:00, 22 June 2015 (UTC)