Difference between revisions of "ISFDB:Community Portal/Archive/Archive45"

From ISFDB
Jump to navigation Jump to search
(archive through October 2018)
(archive older)
 
Line 2,780: Line 2,780:
 
:I agree with this. ···[[User:Nihonjoe|<font color="darkgreen">日本穣</font>]] · <small>[[Special:Contributions/Nihonjoe|<font color="blue">投稿</font>]] · [[User talk:Nihonjoe|Talk to Nihonjoe]]</small> 15:59, 30 October 2018 (EDT)
 
:I agree with this. ···[[User:Nihonjoe|<font color="darkgreen">日本穣</font>]] · <small>[[Special:Contributions/Nihonjoe|<font color="blue">投稿</font>]] · [[User talk:Nihonjoe|Talk to Nihonjoe]]</small> 15:59, 30 October 2018 (EDT)
 
::Change made. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 13:45, 3 November 2018 (EDT)
 
::Change made. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 13:45, 3 November 2018 (EDT)
 +
 +
== Merging illustrations ==
 +
 +
What's the proper procedure for merging [http://www.isfdb.org/cgi-bin/title.cgi?1919797 this] and [http://www.isfdb.org/cgi-bin/title.cgi?2458519 this] without having title variants? [[user:Rtrace]] has confirmed they are the same W&B illustration, and the "Tiffany on the Chalk" title is taken from Kidby's website. [[User:Circeus|Circeus]] 10:37, 1 November 2018 (EDT)
 +
: Two options:
 +
: * Rename them to have the same title - then merge them. However, if the title of the picture is not in the book, it should not be named that way - we follow the naming inside of the book.
 +
: * If the names remain different, they need to be varianted. For art, varianting means: "it is the same picture (more or less - it can have changes in coloring and what's not) but it has a different title in different publications".
 +
: Names from the artist's site go into the notes; if the illustration is not named this way IN the book, the title is not used as a title here usually. Being interior art leaves some leeway but... I would still not name it based on a site.
 +
: Let me know if any more clarifications are needed or if you need assistance. :) [[User:Anniemod|Annie]] 11:49, 1 November 2018 (EDT)
 +
::Please don’t merge or variant those titles.  One is an overall interiorart title for an entire book. It contains the other, but also contains the other artwork in the book. --Ron ~ [[User:Rtrace|Rtrace]]<sup>[[User talk:Rtrace|Talk]]</sup> 13:36, 1 November 2018 (EDT)
 +
:::They are both identical full-page illustrations. Why shouldn't they be merged?  [[User:Circeus|Circeus]] 13:40, 1 November 2018 (EDT)
 +
:::: Because (looking at Ron's page)the record in Ron's book is NOT JUST for that illustration but for all the internal artwork in the book. [[User:Anniemod|Annie]] 14:44, 1 November 2018 (EDT)
 +
:::::Precisely right.  Sorry for the terseness of the previous comment, I was on my cell phone.  We have [[Template:TitleFields:TitleType#INTERIORART|three different ways]] by which we enter INTERIORART.  Unfortunately, we don't have a good way of linking titles for individual artwork to a title that contains multiple artworks.  You could certainly add a note on either or both of the title records explaining the relationship.  I will note that the individual artwork can be linked with [http://www.isfdb.org/cgi-bin/title.cgi?2312612 this title].  It's a little complicated since one of the pieces is technically a translation.  I do question whether the illustration French book really has an English caption.  If so, would we still consider the language of that title to be French?  Also, does the French book contain only that illustration and omit the headpieces and other decorations?  If they are present, there should probably be an overall artwork title for the French translation instead of cataloging only the one illustration.  Circeus, do you own or have access to the translation?  If so, please verify what artwork exists there and we can figure out how to proceed.  Thanks.  --Ron ~ [[User:Rtrace|Rtrace]]<sup>[[User talk:Rtrace|Talk]]</sup> 19:48, 1 November 2018 (EDT)
 +
 +
'''Three months later.''' <br>For what it's worth: In the Contents list for a publication that reprints multiple single illustrations from an earlier INTERIORART work --that is, selections from a previously published set of illustrations-- I would like to see us use titles such as
 +
: Alice in Slumberland [1]
 +
: Alice in Slumberland [2]
 +
rather than omit disambiguation for the title of the first one. As an alternative, we might disambiguate that first single-illustration excerpt from the original work thus:
 +
: Alice in Slumberland (excerpt)
 +
: Alice in Slumberland [2]
 +
 +
As a less radical suggestion, we might add such a title disambiguator only if the entire original INTERIORART work is in the database. <small>(Commonly that will be when the first publication of the latter is added to the database. Commonly too, however, we have many-a-record of a publication in which one set of illustrations is published for the first time, but our publication record does not report the illustrations. So the less radical change of title --for the TITLE that represents one illustration later reprinted from a set-- from "Alice in Slumberland" to "Alice in Slumberland [1]" would happen when we add the set of illustrations to our record of its first publication.)</small>
 +
 +
Also less radical, we might assign to a single-illustration excerpt the date of its earliest known publication. "Alice in Slumberland (excerpt)" isn't first published when "Alice in Slumberland" (entire) is first published. --[[User:Pwendt|Pwendt]]|[[User talk:Pwendt|talk]] 16:56, 25 January 2019 (EST)
 +
--[[User:Pwendt|Pwendt]]|[[User talk:Pwendt|talk]] 16:56, 25 January 2019 (EST)
 +
: (re-word and mark-up, above, for clarity)
 +
: Either of the less radical suggestions will be adequate to ensure that Alice in Slumberland (1898) does not appear in the database as the title of both the 1898 set of illustrations and any later publication of one illustration from the set.
 +
 +
: By the way, can anyone judge how commonly we do have one single-illustration title such as "Alice in Slumberland [2]" now in use for reprints of different illustrations from the original set? --[[User:Pwendt|Pwendt]]|[[User talk:Pwendt|talk]] 13:05, 26 January 2019 (EST)
 +
 +
== Advanced Searche changes -- wildcards ==
 +
 +
The other day the ISFDB server experienced a temporary slowdown. It turns out that it was due to an attempt to retrieve a complete list of ISFDB authors using Advanced Author search. The offending user ran a search on "%", one of our wildcard characters. In order to prevent future performance problems, Advanced Search has been modified to disallow search values which are limited to "%", "*" and "_". [[User:Ahasuerus|Ahasuerus]] 15:15, 1 November 2018 (EDT)
 +
 +
== EditPub and EditTitle -- changing author order ==
 +
 +
As [[Template:AllFields:Collaborations]] states:
 +
 +
*  If a work has multiple authors, it doesn't matter in which order you enter them. The ISFDB does not record author order regardless of how the authors are entered
 +
 +
The order in which authors were entered has always been ignored when filing data into the database. However, Edit Publication and Edit Title used to allow creating submissions which changed author order. It didn't actually ''do'' anything when the submission was approved, but it could be misleading.
 +
 +
The software has been updated to make it clear that changing author order doesn't create a meaningful submission. [[User:Ahasuerus|Ahasuerus]] 21:21, 1 November 2018 (EDT)
 +
 +
== Jim McLeod ==
 +
 +
In the author record for [http://www.isfdb.org/cgi-bin/ea.cgi?110181 Jim McLeod], is the artist who worked from 1970 to 1988 a different person than the horror reviewer who worked from 2011 to present (and who spells his name "Mcleod")? It seems like a certainty they must be different but I can't actually confirm it. --[[User:Vasha77|Vasha (cazadora de tildes)]] 16:19, 2 November 2018 (EDT)
 +
:I think the question should be the other way around. Unless there is something that indicates they are the same (and I'm not seeing it), they should be separated. The time periods and activities are different enough that we shouldn't assume they are the same person. There is nothing about artwork on the provided website link. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 16:43, 2 November 2018 (EDT)
 +
::I have separated the two. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 13:44, 3 November 2018 (EDT)
 +
 +
::: Thanks, but McLeod (I) should be spelled "Mcleod." --[[User:Vasha77|Vasha (cazadora de tildes)]] 15:46, 3 November 2018 (EDT)
 +
::::Done. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 15:49, 3 November 2018 (EDT)
 +
 +
== Canonical name change: John Trevena  ==
 +
 +
I suggest changing [http://www.isfdb.org/cgi-bin/ea.cgi?192813 John Trevena]'s canonical name to Ernest G. Henham. It is as commonly found as Trevena (now that I have just added another title as by Henham) and this is the form used in SFE3. --[[User:Vasha77|Vasha (cazadora de tildes)]] 16:57, 2 November 2018 (EDT)
 +
:Looks like it was done. ···[[User:Nihonjoe|<font color="darkgreen">日本穣</font>]] · <small>[[Special:Contributions/Nihonjoe|<font color="blue">投稿</font>]] · [[User talk:Nihonjoe|Talk to Nihonjoe]]</small> 13:27, 4 November 2018 (EST)
 +
 +
== ''Haunted Houses'' ==
 +
 +
Wanted to get some more opinions on [http://www.isfdb.org/wiki/index.php/User_talk:Auric#Haunted_Houses_2 a discussion] ... it's about a book titled ''[http://www.isfdb.org/cgi-bin/pl.cgi?634331 Haunted Houses]'', for which the publisher's description is "... discusses ten documented cases of ghosts and poltergeists from the past and present and suggests various theories to explain them." I think that it is outside the scope of this DB because it is a nonfiction book about real-life paranormal phenomena; however, the verifier, Auric, argues that it is fiction because "The LC Catalog puts it under 'Ghosts--Juvenile literature'. Also nonfiction is subjective, and depends on whether or not you believe in ghosts." Anyone else? --[[User:Vasha77|Vasha (cazadora de tildes)]] 18:26, 4 November 2018 (EST)
 +
:Sorry - jumped in on the conversation instead. The LC (sub)classification of Juvenile literature does not mean fiction. They have biographies sub-classified as such. For this particular title, they have a Dewey Decimal number of 133 which is non-fiction. As to the second argument - is the classification of religion as nonfiction subjective and depends on whether you believe in God? ../[[User:Holmesd|Doug H]] 10:08, 6 November 2018 (EST)
 +
 +
:: We typically determine whether a work is fiction by examining the way it is presented. Stories like:
 +
 +
::* "I Was Kidnapped and Experimented on by Aliens"
 +
::* "Secrets of Creation as Told by an Angel"
 +
::* "My House Is Haunted"
 +
 +
:: are considered fiction if they are presented as fictional, i.e. not real, stories. Otherwise they are considered non-fiction. [[ISFDB:Policy]] says "Psychic and extrasensory abilities, including but not limited to clairvoyance, levitation, precognition, telekinesis, telepathy and teleportation, when presented as real [are considered speculative fiction]".
 +
 +
:: We have occasionally run into a couple of issues with this definition. The first one is raised by works which facetiously claim that they are non-fiction. In some cases it's not immediately clear whether the author was being facetious or not. The second one is the publisher using the classic "Truth or Fiction? You Decide!" stunt.
 +
 +
:: When in doubt, we generally enter the work and add comments. [[User:Ahasuerus|Ahasuerus]] 12:42, 6 November 2018 (EST)
 +
 +
:::The phrase that the work "suggests various theories to explain them" does heavily point in the direction of nonfiction: it seems that also non-supernatural explanations are discussed. [[User:Stonecreek|Stonecreek]] 00:24, 7 November 2018 (EST)
 +
 +
:::: Are we agreed that this,one should go? --[[User:Vasha77|Vasha (cazadora de tildes)]] 13:29, 17 November 2018 (EST)
 +
 +
:::::: Am I misreading something here? The part of the policy, specifically ''... when presented as real'' Ahasuerus cited above actually says to keep it?! [[User:MagicUnk|MagicUnk]] 17:42, 17 November 2018 (EST)
 +
 +
::::::: The other way around: that's one of the things that is ''excluded'' from the DB. --[[User:Vasha77|Vasha (cazadora de tildes)]] 17:54, 17 November 2018 (EST)
 +
:::::::: No, it is not; it is currently under the inclusion section of the policy. The ''Haunted Houses'' case mentioned above is presented as real, so is included. [[User:MagicUnk|MagicUnk]] 01:29, 21 November 2018 (EST)
 +
:::::::: Re-reading the Policy, I think it must be reworded to be clearer; instead of ''...when presented as real'', it should read ''...when presented as if it were real'' [but is not]. That would correctly convey the intent of the rule, I think. [[User:MagicUnk|MagicUnk]] 06:37, 21 November 2018 (EST)
 +
 +
::::::::: Technically, all bullets in the "Inclusions" section are under "speculative fiction", so they only cover ''fiction'' works. However, since the "occult fiction" bullet clarifies that it's limited to fiction, we might as well do the same for "psychic and extrasensory abilities" in order to avoid confusion. I have changed "when presented as real" to "when presented as if they were real" -- thanks! [[User:Ahasuerus|Ahasuerus]] 12:47, 30 November 2018 (EST)
 +
 +
== Amazon image cleanup ==
 +
 +
The post-submission pages associated with New/Add/Clone/Edit Publication submissions have been enhanced. They now display a warning if an Amazon image URL contains additional formatting like ".SY346."
 +
 +
A new cleanup report has been coded and deployed; the data (approximately 1540 publications) will become available tomorrow morning. The report is available to all editors. At this time the report doesn't support the ability to "ignore" records. If we find Amazon URLs that have legitimate "L._" formatting, we will re-evaluate our options. [[User:Ahasuerus|Ahasuerus]] 18:47, 5 November 2018 (EST)
 +
 +
== Jeanne Cook/Gini Koch ==
 +
 +
Is there some reason why Gini Koch's canonical name is [http://www.isfdb.org/cgi-bin/ea.cgi?137218 Jeanne Cook]? Are we using her real name to avoid having to choose between her pseudonyms? She uses Koch most often by far, and as for it being better known ... two recent publications were billed as "Gini Koch writing as Anita Ensal" and "Gini Koch writing as A. E. Stanton." --[[User:Vasha77|Vasha (cazadora de tildes)]] 17:08, 6 November 2018 (EST)
 +
 +
: IIRC, she used a number of pen names in 2009-2011. It wasn't clear which one (if any) would become dominant, so we used "Jeanne Cook" as a stopgap measure. At this point it's abundantly clear that "Gini Koch" has won the race and should be made the canonical name. [[User:Ahasuerus|Ahasuerus]] 17:56, 6 November 2018 (EST)
 +
 +
:: All edits have been submitted --[[User:Vasha77|Vasha (cazadora de tildes)]] 22:45, 7 November 2018 (EST)
 +
 +
::: All approved and I finished the mopping up. Should be all set. [[User:Anniemod|Annie]] 00:03, 8 November 2018 (EST)
 +
 +
:::: Looks good, thanks --[[User:Vasha77|Vasha (cazadora de tildes)]] 00:16, 8 November 2018 (EST)
 +
 +
== External ID Search enhancements ==
 +
 +
The External ID Search has been enhanced to support the following conditions:
 +
 +
* is exactly
 +
* contains
 +
* does not contain
 +
* starts with
 +
* does not start with
 +
* ends with
 +
* does not end with
 +
 +
The publication table that it generates is currently limited to the first 300 matching publications for performance reasons. [[User:Ahasuerus|Ahasuerus]] 20:17, 7 November 2018 (EST)
 +
 +
: Thanks! That is very useful in chasing identifiers that were set as the wrong type (for the ones that are not just numbers anyway). [[User:Anniemod|Annie]] 17:30, 8 November 2018 (EST)
 +
 +
:: The search logic has been further enhanced to redirect to the Publication page if only one matching publication record has been found. [[User:Ahasuerus|Ahasuerus]] 11:42, 14 November 2018 (EST)
 +
 +
== Cleanup reports and invalid HTML lists in notes ==
 +
 +
The cleanup reports which look for bad HTML in notes have been enhanced to search for "li" tags without corresponding "ul"/"ol" tags. The new data will become available tomorrow morning. [[User:Ahasuerus|Ahasuerus]] 11:03, 8 November 2018 (EST)
 +
 +
== Audio books and page counts ==
 +
 +
It turns out that we have 3K+ audio books whose page count is set to "0". "0" page counts are not displayed on publication pages or in publication tables, so the problem is currently masked.
 +
 +
Would anyone happen to remember if using "0" for audio books was a conscious decision? I can't find anything relevant in our SourceForge archives. [[User:Ahasuerus|Ahasuerus]] 11:58, 8 November 2018 (EST)
 +
 +
: I seem to remember that at least some of the types were producing a bibliographic error when the field was left as 0 - and some people were adding 0 just to make it stop. Not sure how many of them came this way but that may account for some of them.  [[User:Anniemod|Annie]] 17:29, 8 November 2018 (EST)
 +
 +
(unindent) {{Bug|716}} has been created to address the fact that "0" page counts are not displayed.  {{SR|144}} has been created to blank out audio books' "0" page counts programmatically. [[User:Ahasuerus|Ahasuerus]] 14:28, 12 November 2018 (EST)
 +
 +
: All 2,423 audio books with "0" page counts have had the field blanked out. We also have 1,432 ebooks and 119 webzine issues with "0" page counts. We may want to consider taking the axe to them as well. [[User:Ahasuerus|Ahasuerus]] 15:59, 14 November 2018 (EST)
 +
 +
== Geoff Brown ==
 +
 +
For a while horror editor and publisher [http://www.isfdb.org/cgi-bin/ea.cgi?169499 Geoff Brown] used the name "G. N. Braun" on the fiction he wrote; we had that as his canonical name, assuming (I suppose) that fiction would be better known. However, the majority of his web presence and interviews are under the name "Geoff Brown," and this year he started republishing the "Braun" fiction as by "Brown" (two stories so far that I know of). Is it time to change his canonical name yet? I actually was thinking that "Brown" should be the canonical name even before he started republishing the stories, and suggested it a couple years ago. --[[User:Vasha77|Vasha (cazadora de tildes)]] 21:46, 8 November 2018 (EST)
 +
 +
: Help currently says that "the canonical name is the most recognized name for that author within the genre". I suppose if a fiction author is "most recognized" as an editor (H. L. Gold, Howard Browne, John W. Campbell, etc), the canonical name would be his "editor" name as opposed to the "fiction author" name. We even use {{A|R. S. Richardson}} as the canonical name (as opposed to {{A|Philip Latham}}, the pseudonym that he used for his fiction) because Richardson was somewhat better known for his non-fiction essays in SF magazines.
 +
 +
: In this case I think the case for "Geoff Brown" is strong enough to warrant action. [[User:Ahasuerus|Ahasuerus]] 13:43, 10 November 2018 (EST)
 +
 +
== Newford (de Lint) reading order ==
 +
 +
I'd like to update the reading order for the [http://www.isfdb.org/cgi-bin/pe.cgi?18491 Newford] series to match the author's [https://www.sfsite.com/charlesdelint/faq01.htm#Newford recommendation].  Do I need reach out the PVers for any affected pubs, or can I just update the titles?  Thanks [[User:Taweiss|TAWeiss]] 13:00, 10 November 2018 (EST)
 +
 +
: Hm, that's a rather tangled web. Since the stories do not need to be read in a particular order (except for the trilogy mentioned by de Lint), one could argue that the publication order is our best bet. Then again, perhaps putting juvenile and young adult books in a separate sub-series may not be a bad idea. Ditto the horror/thriller books published as by "Samuel M. Key" since they are so different. Decision, decisions... [[User:Ahasuerus|Ahasuerus]] 14:26, 10 November 2018 (EST)
 +
:: de Lint's recommendation would line up with the publication order, so I think that should be updated.  I don't know whether adding a subseries for YA books makes the listing clearer, but I think making sure that the core books are linked makes sense.  Based on my reading, "The Wind in his Heart", probably should be removed, and the three missing books from the author's list should be added to the numbered list. [[User:Taweiss|TAWeiss]] 10:23, 11 November 2018 (EST)
 +
 +
::: I am all for adding the missing books, of course. Re: "The Wind in His Heart" (2017), [https://www.publishersweekly.com/978-1-78636-316-9 this Publishers Weekly review] mentions "Leah Hardin, a Newford blogger", so I assume that it's at least set in the same universe. Perhaps de Lint hasn't had a chance to update the FAQ yet? (It's a very common problem with these kinds of lists.) [[User:Ahasuerus|Ahasuerus]] 12:25, 11 November 2018 (EST)
 +
 +
== Possible new option for adding translations ==
 +
 +
As per [[User_talk:Ahasuerus#Translation_Nice_to_Have_Feature|this discussion]] on my Talk page, there is interest in simplifying the process of adding translated publications to existing title records. As JLaTondre wrote a couple of days ago:
 +
 +
: We are having a lot of translations being entered now. When the translated title doesn't already exist, it is a two step process to add the new book and then variant the translated title to the original. At the title level, it would be nice to have an "Add Translation to This Title" button which would simply be the "Add New Novel" (or whatever one is the equivalent type as the parent) screen, but it would automatically variant the new container title to the original title.
 +
 +
I have poked around a bit and here is what I think. Suppose we have a title like [http://www.isfdb.org/cgi-bin/title.cgi?2244025 this one] and we want to add a translation. Normally, when you click [http://www.isfdb.org/cgi-bin/edit/addpub.cgi?2244025 Add Publication to This Title], the following fields are grayed out:
 +
 +
* Title
 +
* Transliterated Title(s)
 +
* Author(s)
 +
* Pub Type
 +
 +
The proposed option, which we will tentatively call "Add Translated Publication to This Title", will look the same with the following exceptions:
 +
 +
* title, transliterated title(s), and author(s) will ''not'' be grayed out
 +
* a new drop-down list, "Language", will be added
 +
* a new field, "title note", will be added. It will be used to capture the name of the translator(s) and/or any other translation-specific information.
 +
 +
The new data entry form will create a submission which, once approved, will create a new title record using the entered title/transliterated title(s)/author(s)/language/title note. It will also turn the newly created title into a variant of the original title. The new title will inherent the values of the "title flags" from the parent title.
 +
 +
Does this sound about right? [[User:Ahasuerus|Ahasuerus]] 15:26, 10 November 2018 (EST)
 +
 +
: Sounds useful, yes. The form will be the same as Add New Publication except for lacking title flags? --[[User:Vasha77|Vasha (cazadora de tildes)]] 16:03, 10 November 2018 (EST)
 +
 +
:: It will be a cross between Add New Publication and Add Publication to This Title. Unlike the former, there will be no Synopsis field and no Series fields. We could add a "Web Page" multi-field since Web pages are valid for variant titles. [[User:Ahasuerus|Ahasuerus]] 16:19, 10 November 2018 (EST)
 +
::: Yes, please :) [[User:MagicUnk|MagicUnk]] 16:59, 10 November 2018 (EST)
 +
 +
:::: This field would really be nice to have. [[User:Stonecreek|Stonecreek]] 00:18, 11 November 2018 (EST)
 +
 +
::::: That reminds me ... does anyone have bright ideas for how to not display Content field when editing titles except if they're OMNIBUS? I keep pasting web links in that field by mistake ... --[[User:Vasha77|Vasha (cazadora de tildes)]] 18:00, 10 November 2018 (EST)
 +
 +
:::::: The larger issue here is that certain title fields only apply to certain title types. Since the Edit Title form lets you change the values of multiple fields, including the title type value, it can result in inconsistencies. Here are some of the ways in which we currently handle these issues:
 +
 +
::::::* Disallow changing the title type. This is currently done for REVIEWs and INTERVIEWs because you can't easily convert them to other title types.
 +
::::::* Gray out certain fields based on the title type. This is currently done for the two Series fields when editing CHAPBOOK titles. It's not a great solution since the fields remain grayed out even after changing the title type.
 +
::::::* Add pop-up validation to prevent editors from creating invalid records. This is what happens when an editor enters a value in the Content field for a non-OMNIBUS title or a "Length" value for a non-SHORTFICTION title.
 +
::::::* Cleanup reports. Lots and lots of cleanup reports.
 +
 +
:::::: One way to handle this issue would be to make the data entry form logic immediately gray out and "ungray out" relevant fields when the value of the Title Type field is changed. Changing the title type from OMNIBUS to something else would blank and gray out the Content field. Changing it to CHAPBOOK would blank and gray out the two Series field. Etc.
 +
 +
:::::: The problem with this approach is that blanking no longer relevant fields becomes a problem if the editor decides to change the title type again. The only way to get the zapped data back would be to hit F5, but then the rest of the new data would disappear. This is the reason why I originally decided to use pop-up validation instead of graying/ungraying fields on the fly. If there is a better way to do this, I will be more than happy to implement it! [[User:Ahasuerus|Ahasuerus]] 12:17, 11 November 2018 (EST)
 +
 +
(unindent) OK, {{FR|1222}} has been created. [[User:Ahasuerus|Ahasuerus]] 14:23, 12 November 2018 (EST)
 +
 +
== Cleanup reports: "HTML in Notes" tweaked ==
 +
 +
While working on another requested feature, I noticed that some Notes cleanup reports used incompatible lists of disallowed HTML tags. The lists have been consolidated and streamlined based on what's currently stated in [[Help:Using Templates and HTML in Note Fields#Supported HTML tags]].
 +
 +
Once the nightly reports run overnight, the affected reports will include a few new records which mostly use the "small" tag. It's a harmless tag, so if we decide that it's useful, we can trivially add it to the list of supported tags. [[User:Ahasuerus|Ahasuerus]] 19:47, 10 November 2018 (EST)
 +
 +
== Bug? ==
 +
 +
Hi Ahasuerus, I just noticed that when I am clicking on the question mark next to the Graphic Format flag of a New Chapbook, I'm redirected to [http://www.isfdb.org/wiki/index.php?title=Template:PublicationFields:Graphic http://www.isfdb.org/wiki/index.php?title=Template:PublicationFields:Graphic], which is empty, instead of to [http://www.isfdb.org/wiki/index.php?title=Template:PublicationFields:GraphicFormat http://www.isfdb.org/wiki/index.php?title=Template:PublicationFields:Graphic<b>Format</b>]. [[User:MagicUnk|MagicUnk]] 06:00, 11 November 2018 (EST)
 +
 +
: Fixed -- thanks for identifying the problem! [[User:Ahasuerus|Ahasuerus]] 10:22, 11 November 2018 (EST)
 +
 +
== Mirandese Language ==
 +
 +
The software has been updated to add support for the Mirandese language. [[User:Ahasuerus|Ahasuerus]] 10:35, 11 November 2018 (EST)
 +
 +
== Post-submission warnings -- HTML in notes and titles ==
 +
 +
Post-submission pages have been enhanced to display yellow warnings for HTML tags within titles and for invalid/mismatched HTML tags in Notes. The code is brand new and doesn't cover every possible permutation, but it's better than nothing. [[User:Ahasuerus|Ahasuerus]] 18:56, 11 November 2018 (EST)
 +
 +
: Something is off when there is some more complicated HTML. [http://www.isfdb.org/cgi-bin/view_submission.cgi?4041661 this] just decided to show me yellow and it is clean. Another one earlier had a similar problem. The change here is swapping a link with a templated OCLC and I checked 3 times that I did not mess up the only line I edited. Not sure what the parser is catching up on - the report never flagged anything and I do not see a problem either...[[User:Anniemod|Annie]] 19:13, 11 November 2018 (EST)
 +
 +
:: I think I see what the problem is. Let me see if I can fix it real quick. [[User:Ahasuerus|Ahasuerus]] 19:52, 11 November 2018 (EST)
 +
 +
::: If the guess is the "a" tags, [http://www.isfdb.org/cgi-bin/mod/pv_update.cgi?4041714 this] confirms it. No other HTML here... [[User:Anniemod|Annie]] 19:53, 11 November 2018 (EST)
 +
 +
:::: Links and tables, basically. Hopefully the patch that I installed a couple of minutes ago took care of them. [[User:Ahasuerus|Ahasuerus]] 20:09, 11 November 2018 (EST)
 +
::::: Links don't alert anymore - will keep an eye for other anomalities. Thanks for adding this check! [[User:Anniemod|Annie]] 20:15, 11 November 2018 (EST)
 +
 +
:::::: Sure thing. No extra charge for the bugs! [[User:Ahasuerus|Ahasuerus]] 20:46, 11 November 2018 (EST)
 +
 +
(unindent) When you have a chance, can you see why [http://www.isfdb.org/cgi-bin/view_submission.cgi?4046272 this] did not alert about the missing /a and the missing quotes around the href. These are two of the most common issues with html submissions so it will be great if we can see a warning for them. [[User:Anniemod|Annie]] 01:21, 15 November 2018 (EST)
 +
 +
: The invalid HTML report does not catch it either (the missing quotes in href did) - so maybe the missing quotes are throwing off the parser - thus neither the report, nor the new warning system sees it. [[User:Anniemod|Annie]] 01:24, 15 November 2018 (EST)
 +
 +
:: Any ideas here? [[User:Anniemod|Annie]] 13:48, 16 November 2018 (EST)
 +
 +
::: Sorry, I missed the original question. I'll take a look when I am feeling better. [[User:Ahasuerus|Ahasuerus]] 15:05, 16 November 2018 (EST)
 +
 +
:::: Sorry, did not want to nag. Feel better. [[User:Anniemod|Annie]] 15:24, 16 November 2018 (EST)
 +
 +
::::: No problem. At the very least the problem needs to be documented. {{FR|1225}} has been created. [[User:Ahasuerus|Ahasuerus]] 16:08, 16 November 2018 (EST)
 +
 +
== Plates? ==
 +
 +
Concerning ''The Treasure of the Isle of Mist'' T{{t|2215219}}, in a 1934 edition not yet in the database (AddPub is now in the queue as "to be continued"). Full view of this publication is available at HathiTrust, presumably because there is no 1934 copyright statement for the new illustrations. The text is pre-1923.
 +
 +
I diagnosed "plates ''included'' in the pagination" by reference to the numbered pages. For instance the 4-page span pp. 5-8 --two leaves on the usual use of odd and even numbers-- is represented by unnumbered pages that display a small drawing, a caption, a full-page drawing (listed by that caption in "Illustrations" as page 7), and nothing. See [https://hdl.handle.net/2027/uc1.b4104054?urlappend=%3Bseq=27 page 7 at HathiTrust], for one point of entry. Probably those are two plates, eh?
 +
 +
But another listed illustration corresponds to a span of 3 unnumbered pages only, pp. 171-173, which display small drawing, caption, and full-page drawing. See [https://hdl.handle.net/2027/uc1.b4104054?urlappend=%3Bseq=193 page 173]. Relying on the usual use of odd and even numbers, one page of the text, p. 174, is printed on the back of that full-page drawing. --[[User:Pwendt|Pwendt]]|[[User talk:Pwendt|talk]] 19:09, 11 November 2018 (EST)
 +
 +
P.S. The Library of Congress has a record of this edition, LCCN: [https://lccn.loc.gov/34027187 34-27187], which reports "plates". That means leaves of distinct paper stock, right? And normally the text is printed on other leaves. (I say "normally" but I have previously taken it for granted as universal.) --[[User:Pwendt|Pwendt]]|[[User talk:Pwendt|talk]] 19:27, 11 November 2018 (EST)
 +
 +
== Alternate Titles field ==
 +
 +
(copied from R&S) ... [Software improvements could help with ongoing issues]
 +
*Firstly, adding equivalency of capital/small letters in Cyrillic and other alphabets ... (and while you're at it, improved handling of non-Latin-1 characters in the Roman alphabet too).
 +
*Secondly, adding the ability to ignore punctuation when searching and checking for duplicates.
 +
*Thirdly (perhaps as a stopgap in place of the other two suggestions), following up on a suggestion which was made some while ago, to add a field for alternate titles which differ only in punctuation or accents; the alternate titles in this field wouldn't be displayed (they wouldn't be mouseover text like transliterations are) but would help with searching.
 +
--[[User:Vasha77|Vasha (cazadora de tildes)]] 15:49, 11 November 2018 (EST)
 +
 +
:: Re: "adding equivalency of capital/small letters in Cyrillic and other alphabets", it's certainly desirable and important. However, it's not really "adding functionality", it's "upgrading/replacing the database engine". Think of it as replacing a gasoline engine with a diesel engine: doable but time-consuming and but has all kinds of ramifications for the vehicle. Given my other current responsibilities (Fixer, maintenance, e-mail communications with 3rd parties like SFE3 and MIT, Wiki, etc) and my less than stellar health/energy/ability to learn new things these days, big projects like that are a steep hill to climb. We could really use another developer or two. During the summer I helped a volunteer set up a separate development server, but I haven't heard back from him in a few months. I have other prospects as well, but nothing definite at the moment. Of course, a number of our active editors have development backgrounds, but for some reason they seem to be unwilling to quit their day jobs and concentrate on ISFDB development. Most peculiar! (Fixer tells me that it may have something to do with the rumor that humans like to eat.)
 +
:: Re: "the ability to ignore punctuation when searching and checking for duplicates", the main Duplicate Finder has three modes: Exact, Similar and Aggressive. The last two ignore punctuation. On the searching side, I experimented with different approaches a few months ago, but it turned out to be significantly more complicated that I had expected. Apparently, the guys at Google are well paid for a reason... [[User:Ahasuerus|Ahasuerus]] 16:30, 12 November 2018 (EST)
 +
 +
::: Yes, I remember you've said before that these things aren't really feasible without some change in circumstances (like additional developers). Sorry for bringing them up again. But since real improvements are far off, what do people think of adding a field for this sort of variant titles? We are currently using the transliteration field for the purpose, but it's not the best practice to mix two kinds of data in the same field. --[[User:Vasha77|Vasha (cazadora de tildes)]] 16:49, 12 November 2018 (EST)
 +
 +
:::: Agree re: "it's not the best practice to mix two kinds of data in the same field". The issue has been raised in the past, but no FR has been created (that I recall.) The proposed functionality, as I understand it, would be a subset of the functionality supported by [https://www.loc.gov/marc/bibliographic/bd246.html Field 246, "Varying Form of Title"], which exists to record "alternative form[s] of the title" in the MARC 21 standard. The linked Web page includes various examples. If you would like to pursue this line of thought, we may want to move the discussion to the Community Portal. [[User:Ahasuerus|Ahasuerus]] 20:39, 12 November 2018 (EST)
 +
 +
(unindent) The proposal is to add a field for the purpose of collecting together minor variations in the title (or other author name, etc.) which currently cause the software to not recognize them as the same title (author). Namely, things like non-Latin1 characters (people need to be able to find Helen Oyeyemi's story "Dornička and the St. Martin's Day Goose" even if they type "Dornicka"), and minor differences in punctuation like whether there is or is not an Oxford comma. There are also existing instances in this database of the Transliterated Title field being used to store other types of variation that are on the MARC 21 page Ahasuerus linked, such as entering "One Hundred Cats" as an alternate to "100 Cats." The proposed new field would never be visible to users (it wouldn't be mouseover text like transliterations are), but it would be used by the software in searching.
 +
 +
This would be just an ad-hoc thing as a stopgap until (at whatever future time) the software
 +
is improved. People would simply enter whatever variants they can think of. We have already put some of that into the transliteration field; it would be a moderate-size cleanup project to move it to the new field and leave Transliterated Title for just transliterations from one alphabet to another. --[[User:Vasha77|Vasha (cazadora de tildes)]] 21:45, 12 November 2018 (EST)
 +
:Easier solution is to use Google. Add a new search option on the Advanced Search that uses a Google search with predefined syntax that limits the search to ISFDB and with specific words (Title, Publication, Summary Bibliography, Publication, etc.) in the page title. For the Dornicka example, <code>site:www.isfdb.org intitle:title Dornicka</code> will search only ISFDB for pages that have Title in their title (i.e. title records), and matches Dornicka which correctly returns "Dornička and the St. Martin's Day Goose"  ([https://www.google.com/search?q=intitle:title+Dornicka&domains=www.isfdb.org&sitesearch=www.isfdb.org try it]). It would consist of a single pull down to select page type and a text box. That would be a lot easier than adding new fields (which need to be added to the database, multiple forms, search options, etc.) and also then need to be populated. Search engines are great at fuzzy matches so let them do their thing vs. recreating it in a much less ideal way. It will search the whole page, not just a particular field, which can either be a downside or a plus depending on your goal. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 07:35, 13 November 2018 (EST)
 +
 +
:: It would be easy to add a "Google Search" option to Advanced Search. We could even add a context-sensitive "Google Search" check mark to the main search box. (The reason it would have to be context-sensitive is because a Google search on "Year of Title = 1872" wouldn't work too well.)
 +
 +
:: However, keep in mind that Google's data is typically a few weeks behind, so it won't find any recently added/changed data.
 +
 +
:: I am thinking that the low-hanging fruit would be to add a "Google Search" section to Advanced Search, which can be done quickly, and see what happens. [[User:Ahasuerus|Ahasuerus]] 08:26, 13 November 2018 (EST)
 +
:::Yes, Google search isn't the ideal solution. However, I think it's better than the suggested interim solution given the trade between work & benefit. Though my over all preference would be doing neither since there is other work I'd personally rate higher. So maybe I'm biased. ;-) --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 11:35, 13 November 2018 (EST)
 +
 +
:::: That'd help. But would it allow the stuff that doesn't belong in the transliteration field to be removed, or would we still need that? There's an existing cleanup report that mandates entering an alternative to non-Latin1 characters --[[User:Vasha77|Vasha (cazadora de tildes)]] 12:26, 13 November 2018 (EST)
 +
 +
::::: Well, if you work with Cyrillic titles, you may have a different bias - try to look for an author called Вежинов and then вежинов. :) For example. Now think about how often people hit caps lock or shift by mistake :) Another option is to use the transliterated fields to contain a "lower case only" version of the name amongst the other transliterations and add an explanation to the advanced search (and on the result screens) on how to search in case you cannot find what you are looking for). Thus NO real work (besides a few comments in the search pages) as we already search the transliterations by default. That would be similar to transliterating the kanji in kana for Japanese. Not elegant but... good enough stopgap until we can swap the encoding. And once it is swapped one day, deleting these will be easy (as they will match without case to the main title). And it is similar to the whole alternative title thing... (at least for the search problems) minus the work. Plus there is a case to be made that going to all smalls is a type of transliteration (from an alphabet of A-Za-z to one with a-z)  :) [[User:Anniemod|Annie]] 12:32, 13 November 2018 (EST)
 +
 +
:::::: Uh, no, that is not a transliteration. Someday (hopefully) we are going to have a real solution to the problem of fuzzy searches/capitals in Cyrillic/etc. and then the transliteration field will just be for one alphabet to another (one writing system to another, in the case of kanji-to-hiragana). Why shouldn't we start now with the process of cleaning up that field, putting everything that is not a transliteration into a different field? We have thousands of titles currently where the lowercase version or non-latin1 character or whatever is in the transliteration field, and it would take a few days to go through and move them all; in five years we will have many more thousands—why not enter them into a different field to start with, instead of putting them in the transliteration field where they will eventually have to be removed? --[[User:Vasha77|Vasha (cazadora de tildes)]] 13:13, 13 November 2018 (EST)
 +
 +
::::::: Because I would rather have non-transliteration there than spend 2 (or 5) more years waiting for this DB to become even remotely usable for the titles in my native language. And as they will be exact matches (minus letter size), they will be easy to remove when we have that fixed - so we are not facing a long project pulling them out. Let's be realistic here, shall we? Great ideas and what's not is great BUT spending time to build a solution that will be obsolete when we change encoding is worse than dealing with some additional values in some fields. And dumping all kinds of stuff in a new field would not solve the problem - it will just move it to a new field (what goes there? Small letters ones, kana ones for Japanese? Something else? Everything that is not a transliteration?) Call me pragmatic if you want but I would rather not stress the single developer with something that we live without and where we have a soft solution that does not really degrade the data. [[User:Anniemod|Annie]] 13:29, 13 November 2018 (EST)
 +
 +
::::::: "We have thousands of titles currently where the lowercase version or non-latin1 character or whatever is in the transliteration field" - huh? Noone had added "lowercase" specifically anywhere so I am not sure what you are talking about? [[User:Anniemod|Annie]] 13:29, 13 November 2018 (EST)
 +
 +
:::::::: "Transliteration" has a pretty concrete definition. It is taking a word written in one writing system and coming up with an equivalent in a different writing system. Yes, writing the sounds represented by a kanji character as hiragana is a type of transliteration. I am arguing that the Transliterated Title field should ''only'' be used for transliterations in this sense. Up to now, we have needed a place to store ad-hoc typographic information like the fact that people may search for "č" by typing "c" or the fact that French "œ" is a typographic variant of "oe," and we have put it into the transliteration field, but it isn't the same type of data and shouldn't go there. --[[User:Vasha77|Vasha (cazadora de tildes)]] 13:40, 13 November 2018 (EST)
 +
 +
::::::::: Your claim is that NOW we have "small letters" being added to fields - see what I cited from your post. That's the part I am asking about. Because it is not true - we do not use the field this way now. Even if that would have made the DB usable. I know what transliteration is - both from the Linguistics side and from the Math/IT side. As for what is a valid transliteration - A-Zaz -> a-z is writing the same title in a new "set of characters". Not in the linguistics sense but then a lot of things are not. And œ/oe and Б/б are comparable. Just because the letters set is in the same alphabet does not make it less of a transliteration. Technically speaking. :) And again - moving all that "stuff" to a new field does not solve the issue - it just moves it to a new field. Or are we going to keep adding fields ad-infinitum? [[User:Anniemod|Annie]] 14:44, 13 November 2018 (EST)
 +
 +
:::::::::: But anyway - the point I am trying to make is that building a solution that will be obsolete soon does not make sense - when we can just reuse what we have. It does not matter if it is "clean", in both cases we will need to deal with it once the real solution is in place. Add effort, time to execute and all that and as much as I like clean solutions, I would take any solution at this point. [[User:Anniemod|Annie]] 14:56, 13 November 2018 (EST)
 +
 +
=== Types of Alternate Titles/Values ===
 +
 +
Let me take a step back and try to list the different types of "alternate titles/values" that we are discussing here. (I prefer "values" to "titles" because the discussion also includes authors, publishers, etc.)
 +
 +
First, here are the scenarios that are currently supported by our implementation of "transliterated values":
 +
 +
* Romanized versions of non-Latin values. The current implementation supports multiple versions per original value, e.g. "Arifureta Shokugy'''ō''' de Sekai Saiky'''ō''' 1" as well as "Arifureta Shokugyou de Sekai Saikyou 1" for "ありふれた職業で世界最強 1".
 +
* For languages which use multiple alphabets/scripts/writing systems, version(s) of the original title which use alternate systems, e.g. "ありふれたしょくぎょうでせかいさいきょう 1" for "ありふれた職業で世界最強 1".
 +
* English versions of Latin titles which use non-English letters, e.g. "Dornicka" for "Dornička" and typographic variants like "œ"/"oe"
 +
 +
Next, here are the new types of alternate values which are being proposed, either to be entered in the requested new field or as additions to the list above:
 +
 +
* Lower case versions of non-Latin values to help with searches
 +
* Alternative forms of the original value like "One Hundred Cats" as an alternate to "100 Cats". It could include other alternative values like the titles found on book covers and spines which we currently enter in Notes (or omit.)
 +
 +
Re: lower case versions of non-Latin values, I think it will only get us so far whether we enter them in the existing Transliterated Values fields or in the requested new field. Adding "павел вежинов" to "Павел Вежинов" won't help users who type "ПАВЕЛ ВЕЖИНОВ". Without full Unicode support, it will remain a band-aid.
 +
 +
Re: alternative values like "One Hundred Cats", it's been discussed a few times. I don't recall any objections, but it appeared to be a low priority. Also, it will remain a valid separate request even after the upgrade to Unicode. If we can reach consensus re: its desirability, I would be in favor of adding it as a separate FR.
 +
 +
Am I missing anything? [[User:Ahasuerus|Ahasuerus]] 17:05, 13 November 2018 (EST)
 +
 +
:: Punctuation is mIssing. Right now typing "X - Y" into the search box won't find "X—Y" and vice versa, nor will "X, Y, and Z" match "X, Y and Z." Plus we had a debate a while ago as to whether it was acceptable  to use the transliteration field to enter "X and Y" as an alternative if "X & Y" is printed in the book (who can remember which form to search for?). Finally, I don't agree that typographic matters like c/č and œ/oe properly belong in the transliteration field. --[[User:Vasha77|Vasha (cazadora de tildes)]] 17:25, 13 November 2018 (EST)
 +
 +
::: So what do you call the č -> c (or ch) transition? It is converting Unicode/ to Latin1 which is the definition of transliteration in the IT world. Looking at the linguistics level, it is a transliteration between two Latin standards (in the same way in which Э э get changed to an existing letter in the alphabets that do not have it; or й between the Cyrillic standards)... But the main question still stand - how adding a new field that contains all that funny stuff will be helpful at all and not just moving the problem from one field to another. Just so it is not in the transliterated field? What is the difference? Maybe we should revisit why we have transliterations to start with - assisting reading from non-native editors and users and facilitating search for users that do not have the proper keyboard to create the special characters (or copying from a source that does not have the correct characters when searching). Or is the second not part of why we have the field anymore? :) [[User:Anniemod|Annie]] 17:43, 13 November 2018 (EST)
 +
 +
(Unindent) OK, instead of arguing about what is or is not a transliteration, and what can or can not go in the "Transliterated Title" Field, how about we rename that field to "Alternate Form of Title"? And agree that you can enter anything into that field if you think it'll be helpful? That'll make sense of all the diverse stuff that already is in it. --[[User:Vasha77|Vasha (cazadora de tildes)]] 18:09, 13 November 2018 (EST)
 +
 +
: I think the first step would be to update Help with a list of everything that this field currently supports. After all, there are things that are disallowed at this time, e.g. alternative forms of the main title like the "One Hundred Cats" example above and transliterations that use non-Latin non-native alphabets/scripts. Having the current practices explained in one place (a new Help template, I assume) would get all of us on the same page. With the current rules codified, we would be in a better position to decide whether to:
 +
 +
:* rename the field
 +
:* expand its remit
 +
:* do something else
 +
 +
: [[User:Ahasuerus|Ahasuerus]] 12:49, 14 November 2018 (EST)
 +
 +
:: Results of a survey of current ways this field is used with titles whose language is English--Besides giving alternatives for non-Latin1 characters, there are the following sorts of uses:
 +
 +
::1. Giving text equivalents of titles with symbolical or mathematical elements in them. There are about 50 of these I think; here are a selection:
 +
:::[http://www.isfdb.org/cgi-bin/title.cgi?1422186 Rendezvous 10¹⁰]&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;Rendezvous 10 to the power 10<br>[http://www.isfdb.org/cgi-bin/title.cgi?2111929 eʰ]&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;e^h<br>[http://www.isfdb.org/cgi-bin/title.cgi?902606 Golem¹⁰⁰]&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;Golem 100<br>[http://www.isfdb.org/cgi-bin/title.cgi?1409662 ⁵Limericks]&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;5 Limericks<br>[http://www.isfdb.org/cgi-bin/title.cgi?84885 X ≠ Y]&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;X does not equal Y<br>[http://www.isfdb.org/cgi-bin/title.cgi?1240640 ∞°]&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;Infinity Degrees<br>[http://www.isfdb.org/cgi-bin/title.cgi?1384423 The World of Ā]&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;The World of A&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;The World of Null-A<br>[http://www.isfdb.org/cgi-bin/title.cgi?1652765 fan•dom (fan´ dəm) n. a way of life]&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;fandom (fandum) n. a way of life<br>[http://www.isfdb.org/cgi-bin/title.cgi?2148942 &amp;#x25CD;]&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;"Circle with Vertical Fill" Hex code<br>[http://www.isfdb.org/cgi-bin/title.cgi?2301868 ♋]&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;Cancer<br>[http://www.isfdb.org/cgi-bin/title.cgi?2426044 *]&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;asterisk&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;star<br>[http://www.isfdb.org/cgi-bin/title.cgi?76213 █████]&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;{black bar}&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;[redacted]&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;redacted<br>[http://www.isfdb.org/cgi-bin/title.cgi?41040 Press Enter ▮]&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;Press Enter []<br>[http://www.isfdb.org/cgi-bin/title.cgi?1888173 &lt;3/&lt;/3]&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;less than three slash less than slash three<br>[http://www.isfdb.org/cgi-bin/title.cgi?2363459 Foreword ((1⁴+2⁴+3⁴+4⁴+5⁴)+6⁴+7⁴)]&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;Foreword ((1(to the 4th degree)+2(to the 4th degree)+3(to the 4th degree)+4(to the 4th degree)+5(to the 4th degree))+6(to the 4th degree)+7(to the 4th degree))
 +
::2. Giving "and" as an equivalent to &. Done 33 times with the "and" in the main title, & in the transliteration; twice the other way around.
 +
::3. Giving "plain" equivalents of titles that are written oddly. For example,
 +
:::[http://www.isfdb.org/cgi-bin/title.cgi?1531738 Channel Sk1n]&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;Channel Skin<br>[http://www.isfdb.org/cgi-bin/title.cgi?1132178 βoyfriend]&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;Boyfriend
 +
::4. Multiple attempts at writing titles that cannot be entered the way they are in the book. Here is one I did myself: I represented "How Can I <strike>Help</strike> Hurt You?" as "How Can I Hurt You?" and "How Can I Help Hurt You?"
 +
::5. Punctuation variants (these are pretty rare). A selection of examples:
 +
:::[http://www.isfdb.org/cgi-bin/title.cgi?1529111 Perce Rock ▬ First Sighting]&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;Perce Rock — First Sighting&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;Perce Rock - First Sighting<br>[http://www.isfdb.org/cgi-bin/title.cgi?2132411 Little Green Men—Attack!]&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;Little Green Men Attack<br>[http://www.isfdb.org/cgi-bin/title.cgi?2214461 Never Fear: The Apocalypse]&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;Never Fear—The Apocalypse<br>[http://www.isfdb.org/cgi-bin/title.cgi?2173985 Interstellar Navigation, or Getting Where You Want to Go and Back Again (in One Piece)]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Interstellar Navigation; or, Getting Where You Want to Go and Back Again (in One Piece)
 +
::6. Just plain alternate titles.
 +
:::[http://www.isfdb.org/cgi-bin/title.cgi?2131432 SciFan™ Magazine - 2017]&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;SciFan Magazine - 2017<br>[a cover art title] [http://www.isfdb.org/cgi-bin/title.cgi?2103101 Jump Point, Issue 02.03]&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;Warned
 +
 +
::The first of these categories, at least, seems pretty firmly within the existing mission of the field (the others may be extensions of the mission, and number 6 flat-out wrong). But "Alternate Writing of Title" or some such name seems to describe those text-equivalents better than "Transliteration." --[[User:Vasha77|Vasha (cazadora de tildes)]] 15:26, 14 November 2018 (EST)
 +
 +
::: Why isn't "™" in the first category? This is a special symbol, not two letters with weird formatting (in that writing anyway). Not much different from some of the others in category 1. I would not call that alternative writing - it contains a symbol that people may not be able to create... Just because it looks like letters does not make it letters really - not in a title. [[User:Anniemod|Annie]] 15:46, 14 November 2018 (EST)
 +
 +
:::: Because SciFan Magazine is sometimes written with the TM and sometimes without, and I think this was intended as a way of putting both names in the same record. We should figure out which is the "real" title and/or make them variants of each other. (Not that easy because SciFan Magazine is now defunct and out of print, but ...) --[[User:Vasha77|Vasha (cazadora de tildes)]] 16:01, 14 November 2018 (EST)
 +
 +
::: It occurs to me: "and" is a text-equivalent of "&" so that one, at least, makes sense in the existing conception of the field. --[[User:Vasha77|Vasha (cazadora de tildes)]] 16:20, 14 November 2018 (EST)
 +
 +
(unindent) Attempt at codifying the use of this field (whatever it's called). Currently, it is chiefly for: 1. Transliterations from one writing system to another. 2. Providing Latin1 alternatives to non-Latin1 characters. 3. Spelling out mathematical expressions and symbols in words.
 +
 +
Proposal: As a logical extension of use no. 3, I would like it to be specified that it's acceptable use this field to spell out "&" as "and." Second proposal: spelling out numbers in words; this is also a logical extension of use no. 3.
 +
 +
Other possible uses: spelling out abbreviations? (e.g. vs./versus)? I'm undecided but I think maybe not.
 +
 +
We also have a few quirky miscellaneous uses at present, like the strikethrough example and the Channel Sk1n/Channel Skin example above. There are only a few of these, I don't see a better way to handle them, and as far as I'm concerned they can be left as is, ignored & not mentioned in the codification of the uses of the field.
 +
 +
It seems that this field should NOT be used for variant punctuation. The proposed Google search will take care of it instead (and much better).
 +
 +
Any thoughts on additions/subtractions to this list of uses? I think we are almost ready to write up a description of the field, and then we can debate its name. --[[User:Vasha77|Vasha (cazadora de tildes)]] 01:23, 16 November 2018 (EST)
 +
 +
: Any further thoughts on this? --[[User:Vasha77|Vasha (cazadora de tildes)]] 16:27, 24 November 2018 (EST)
 +
 +
:: Thanks for researching the current patterns of use. One thing that comes to mind is that the proposed Google search functionality may also take care of certain other types of cases like "&" vs "and". It may be better to implement Google search first, see how much we can squeeze out of it, and then revisit this field. [[User:Ahasuerus|Ahasuerus]] 12:15, 27 November 2018 (EST)
 +
 +
::: It is true that Google can handle &/"and." But an argument in favor of entering the alternate text anyway (in just this one case) is the same as the argument in favor of keeping the Latin1-alternative uses of the field: why force people to switch to Google if you have a simple way of getting the direct search to find the desired result? The "and" situation is common (and annoying) and adding alternative text for it would be relatively easy. I don't think we should go hog-wild entering alternative text for all symbols, though. --[[User:Vasha77|Vasha (cazadora de tildes)]] 16:22, 27 November 2018 (EST)
 +
 +
:::: Vasha, I saw you adding one of the &/and today. Let's wait a bit before we start changing things until we agree what we want to do. As annoying as it may be to you, just going ahead and doing something that may need reversal is losing everyone's time in the long run - and makes the DB even less consistent than it is. So let's agree first, then change in whatever direction we agree on. I know it is annoying and we all would love to have things happen faster but everyone doing what they want is not the path forward. :)
 +
 +
:::: I would support adding & as one of the values that makes sense BUT... what about the other direction? Do we really want to add the opposite one for people that may search with &? I do not think so. So if it is one-directional, we need to make some notes on the result page around that. [[User:Anniemod|Annie]] 16:27, 27 November 2018 (EST)
 +
 +
::::: I can think of a few additional issues with "and/&". For example, what should we do about non-English titles/values which use "&"? Should we use "und", "et", "en", "e", "y", etc depending on the language? Also, what should we do if there are multiple ampersands, e.g. [http://www.isfdb.org/cgi-bin/title.cgi?2143404 "Linda & Daniel & Spike"] or [http://www.isfdb.org/cgi-bin/title.cgi?1862411 "Romeo & Julia — Innenansichten von Adam & Eva 2.0"] or even [http://www.isfdb.org/cgi-bin/title.cgi?98529 "Filomena & Greg & Rikki-Tikki & Barlow & the Alien"]? [[User:Ahasuerus|Ahasuerus]] 17:15, 27 November 2018 (EST)
 +
 +
:::::: Yeah, that's a good point... and then the other direction, combined with languages and what's not, gets even muddier. Thus my point - let's first figure out what we are doing before we start doing it :) Nothing is easy when you try to do fuzzy searches by hard-coding values... And that one may be solvable in a different way actually - less manual (details to follow when I work through them in my head). [[User:Anniemod|Annie]] 17:45, 27 November 2018 (EST)
 +
 +
== Narrator Template ==
 +
 +
Can we add a Narrator template for publication notes? That will make it easier to find the books we have that are narrated/read by a certain person (and one day when we have "non-authors connected to books" fields, we can migrate easily. [[User:Anniemod|Annie]] 22:50, 12 November 2018 (EST)
 +
 +
: It would be easy to add a new template for narrators assuming that the functionality is similar to that of the "Translator" template. [[User:Ahasuerus|Ahasuerus]] 08:53, 13 November 2018 (EST)
 +
 +
:: Yep, same idea. :) [[User:Anniemod|Annie]] 12:13, 13 November 2018 (EST)
 +
 +
::: What should we call it then? "Narrator"? Something shorter along the lines of "Tr"? [[User:Ahasuerus|Ahasuerus]] 15:35, 13 November 2018 (EST)
 +
 +
:::: Narrator sounds good to me. Tr made sense but I cannot figure out how to make Narrator shorter without making it too cryptic :) "Reader" also works for me - although it should still be "Narrated by X" when on the page. Or maybe "Narrated/Read by X"... [[User:Anniemod|Annie]] 15:39, 13 November 2018 (EST)
 +
::::: Too long to type. Why not <nowiki>{{narr|...}}? </nowiki>[[User:MagicUnk|MagicUnk]] 16:34, 13 November 2018 (EST)
 +
 +
:::::: Too cryptic if you ask me... But I can live with narr. Or maybe "read"? [[User:Anniemod|Annie]] 16:50, 13 November 2018 (EST)
 +
::::::: Wellll, you could say that of "Tr" too. But once you know what it is, you won't forget. Narr has an advantage over read in that narr == narrated is easier to remember than read == narrator. [[User:MagicUnk|MagicUnk]] 17:19, 13 November 2018 (EST)
 +
 +
:::::::: "Tr. by X" is a standard bibliographical entry though :) Older books called those "readers", now the modern term is "narrator" although some books still say "read by". So they are interchangeable. So for some people the term is reader and not narrator so "narr" will be absolutely undecipherable. I can work with either - and we can always change if needed [[User:Anniemod|Annie]] 17:30, 13 November 2018 (EST)
 +
 +
::::::::: I expect that "read" would be less intuitive than "narrator". Also, since I don't use audio books, I would probably find it hard to remember that "narr" stands for "narrator", but perhaps I would get used to it. [[User:Ahasuerus|Ahasuerus]] 12:33, 14 November 2018 (EST)
 +
 +
:::::::::: I still think that the one that will the least confusing is "Narrator" :) [[User:Anniemod|Annie]] 13:48, 14 November 2018 (EST)
 +
 +
::::::::::: That would be fine by me. [[User:Ahasuerus|Ahasuerus]] 15:00, 14 November 2018 (EST)
 +
:::::::::::: Sure, can live with that :) [[User:MagicUnk|MagicUnk]] 16:59, 14 November 2018 (EST)
 +
 +
=== Narrator Template - Outcome ===
 +
 +
{{FR|1224}} has been created. [[User:Ahasuerus|Ahasuerus]] 10:07, 15 November 2018 (EST)
 +
 +
== Length for Audiobooks ==
 +
 +
On a related note, how long a book runs is comparable to page numbers. So should we add a new field to collect this information (audiobooks are more and more popular) or should we start using the "pages" field instead (as these will never have pages). I am more inclined to go for a new field (two separate pieces of data in the same field is a bad idea) but in this case as a book is either a paper one or an audio one, they are separate enough (and ebooks stay with the current policy of "no number of pages")[[User:Anniemod|Annie]] 22:50, 12 November 2018 (EST)
 +
:If a new field is added, it would be best if the software was smart enough to only display the correct field for the type of pub (i.e. physical books should page number, ebooks show nothing, and audio books show length) instead of always showing them. Or at least only make the correct one editable. Requires the edit form to be a bit smart as have to update the display when the format is changed while editing. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 07:18, 13 November 2018 (EST)
 +
 +
:: I discussed some of the issues with dynamically changing the data based on the title/publication type [[ISFDB:Community_Portal#Possible_new_option_for_adding_translations|here]]. [[User:Ahasuerus|Ahasuerus]] 08:33, 13 November 2018 (EST)
 +
 +
:::Field state (active/inactive, displayed/hidden) can be changed dynamically via JavaScript. [http://jsfiddle.net/pranavcbalan/v4gNL/ Here is an example] that displays a field when one option is chosen but not another. The value is not lost when hidden (in the example, change it to "Business use", enter text, change it to a different state, and the change it back). On the back-end, the submission logic would need to handle the fact there is a no longer needed value and toss it out. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 09:18, 13 November 2018 (EST)
 +
 +
:::: How about the same logic we use for "series" in variants? [[User:Anniemod|Annie]] 12:13, 13 November 2018 (EST)
 +
:::::That doesn't work the reasons Ahasuerus laid out in his above link. It works for series because you cannot make a variant a non-variant from the title edit screen. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 12:45, 13 November 2018 (EST)
 +
:::::: Yeah, missed that one when reading this morning. Oh well... I am not sure what is the problem with just having both and having editors just be careful plus a nightly report that finds values in the wrong field. Considering all the other problematic fields, that one is not even that challenging. I would love a software solution but if there isn't one that works across browsers and what's not, we can live with it :) [[User:Anniemod|Annie]] 14:47, 13 November 2018 (EST)
 +
 +
:: We could add pop-up validation that would disallow "length" values for non-audio formats, but first we would have to decide what to do with combined "paperback+CD" publications. [[User:Ahasuerus|Ahasuerus]] 08:33, 13 November 2018 (EST)
 +
 +
::: Any thoughts re: "paperback+audio" publications? I believe I have only one in my collection, but they have apparently become more popular lately. Their records should presumably allow both types of values. [[User:Ahasuerus|Ahasuerus]] 15:41, 13 November 2018 (EST)
 +
 +
:::: Allow both fields to be populated for that case specifically. That should not be a problem, right? [[User:Anniemod|Annie]] 16:30, 13 November 2018 (EST)
 +
 +
::::: There's an issue with adding fields at the front end: clutters the screen, losing oversight. Therefore, "smart" forms are the way to go. [[User:MagicUnk|MagicUnk]] 16:55, 13 November 2018 (EST)
 +
 +
:::::: This is the part that I am not sure about. Back when we added context-sensitive drop-down lists to the Advanced Search page, some users commented that they didn't understand why values were changing as if by magic. I am concerned that dynamically adding and deleting fields based on the values of certain other fields (like the publication type field) would be even more confusing. [[User:Ahasuerus|Ahasuerus]] 12:40, 14 November 2018 (EST)
 +
::::::: Really? Once upon a time I had something done very similar with an application I defined the functionality for (ie dynamically updating labels dependent on certain type values), and no-one ever complained that was confusing. Au contraire, I definitely got the impression they really ignored it altogether... [[User:MagicUnk|MagicUnk]] 16:54, 14 November 2018 (EST)
 +
 +
:::::::: A lot can depend on the user community, including things like their computer savvy, whether they are occasional users or regular users, etc. [[User:Ahasuerus|Ahasuerus]] 10:06, 15 November 2018 (EST)
 +
 +
::::: (Adding more fields to the database isn't an issue. In fact, on DB level fields should never be used for multiple purposes). There's another way of dealing with using a single input field for two different value types: change the label only, and when saving, the backend logic determines in which field to save the entered data, dependent on title type. Only one field needed, so no keeping track of previously-entered data when switching type.That approach doesn't support the pb+audio though, but it might be useful approach somewhere else... [[User:MagicUnk|MagicUnk]] 16:55, 13 November 2018 (EST)
 +
 +
:::::: Which is where I started - reuse  the field we have now. Technically pb+audio is not different from a boxset where we do 300+300+300 for example... as long as we know what is first :) New field will make it less confusing for new editors BUT more convoluted for us (what do we show on pub lists under a title for example)? [[User:Anniemod|Annie]] 17:27, 13 November 2018 (EST)
 +
::::::: Not sure we were actually saying the same; there's a distinction to be made between adding additional fields on the forms (and hence to the DB as well) - which is what you were proposing if I understood correctly?, as opposed to keeping the UI slick, keep changes and additions to a bare minimum, and only expanding the DB tables with additional attributes. [[User:MagicUnk|MagicUnk]] 16:57, 14 November 2018 (EST)
 +
 +
:::::::: My initial note had two proposals - keep one field for both (type determines what it means) or add a new one. How the DB is designed behind that is irrelevant really - and if we have a single field, doing separate DB fields and from there separate search options will be confusing (and can have performance considerations if someone tries to do a query weirdly) so if we stay in one field, we should just stay in one field if you ask me. :) [[User:Anniemod|Annie]] 19:39, 14 November 2018 (EST)
 +
 +
== Changing data entry forms dynamically -- options ==
 +
 +
I have been thinking about JLaTondre's response above and, more generally, the options that we have when data entry forms end up with internally inconsistent data: CHAPBOOKs with Series data, non-OMNIBUS titles with "Content" data, and so on.
 +
 +
I will first list the options that I was aware of when I was writing  [[ISFDB:Community_Portal#Possible_new_option_for_adding_translations|this comment]]:
 +
 +
# Disallow changing the values of certain key fields to avoid inconsistencies. This is currently done in Edit Title for REVIEWs and INTERVIEWs: you can't easily convert them to other title types.
 +
# Gray out certain fields based on changes to key fields like "title type". This is currently done for the two Series fields when editing CHAPBOOK titles. It's not a great solution since the fields remain grayed out even after changing the title type.
 +
# Add pop-up validation to prevent editors from creating invalid records. This is what happens when an editor enters a value in the Content field for a non-OMNIBUS title or a "Length" value for a non-SHORTFICTION title.
 +
# Dynamically gray out and blank affected fields whenever changes to other fields make them invalid, e.g. Series fields for CHAPBOOK titles. The problem with this approach is that blanking no longer relevant fields becomes a problem if the changes that prompted the blanking are reverted.
 +
# Cleanup reports. Lots and lots of cleanup reports.
 +
 +
In addition, we have the following options when "key" values are changed:
 +
 +
# Dynamically gray out the affected fields, but do not delete their data. That way if the changes to "key" fields are reverted, "ungraying" the affected fields will restore their data. The problem with this approach is that it may confuse editors who won't understand what "grayed out" data means and whether it will be filed into the database upon submission approval.
 +
# Make the affected fields invisible; if the "key" changes are reverted, make them visible again. Would new editors find disappearing fields confusing?
 +
# Dynamically gray out the affected fields, delete their data and save it within the browser (probably using a hidden field, which is what we do in Advanced Search.) If the "key" changes are reverted, use the saved data to restore the affected fields' values.
 +
 +
From a purely technical perspective, it's all doable. Functionally, I think I prefer pop-up validation to the "gray-out"/"invisible" options. I suspect that (but can't be sure) changing the form layout and/or the field status dynamically has the potential to confuse new editors. [[User:Ahasuerus|Ahasuerus]] 16:19, 13 November 2018 (EST)
 +
 +
: I am fine with popups. [[User:Anniemod|Annie]] 16:48, 13 November 2018 (EST)
 +
 +
== Autobiographical titles acquisition ==
 +
 +
For our spec-fic authors, which of their publications about themselves should we include in the database? Any threshold on the author should be lower than that ''certain threshold'' ([[ISFDB:Policy#Included]], point 4) over which all publications should be included.
 +
 +
For instance, in 1936 newspapers I find coverage of the new book ''A Long Retrospect'' as the autobiography of {{a|F. Anstey}} --see [http://lccn.loc.gov/36021029 LCCN: 36-21029] and [http://www.amazon.co.uk/long-retrospect-F-Anstey/dp/B000857ECY ASIN: B000857ECY at Amazon UK].
 +
And I find notice that {{a|Laurence Housman}} has nearly completed his own autobiography --not pursued.
 +
 +
One issue here is routine acquisition from secondary sources, as many works mentioned in SFE3 and The Encyclopedia of Fantasy biographical entries are routinely added. Knowing that the book is by Anstey about Anstey, say. Let me stop here. --[[User:Pwendt|Pwendt]]|[[User talk:Pwendt|talk]] 16:44, 13 November 2018 (EST)
 +
 +
: I don't think we have a separate threshold for autobiographies of primarily non-genre authors. That said, as a collector of all things Anstey, I understand where you are coming from. He wrote a fair amount of notable speculative fiction starting with [http://www.isfdb.org/cgi-bin/title.cgi?19869 ''Vice Versa''], a minor classic of the genre. ''Tourmalin's Time Cheques'' was an early time travel novel which preceded Wells's ''The Time Machine'', etc. Even though we currently don't include his non-genre works, I agree that his autobiography should be included.
 +
 +
: At the same time, I am not really sure how we could address this issue at the Policy level. Adding a new threshold for autobiographies would likely only complicate things, especially considering the nebulous nature of the current "certain threshold" for non-genre works. Perhaps we could include autobiographies as "books ABOUT speculative fiction"? [[User:Ahasuerus|Ahasuerus]] 12:26, 14 November 2018 (EST)
 +
 +
== Question about Connection Security ==
 +
 +
HELP!
 +
I have joined ISFDB only on a temp basis because "The Connection is not Secure" is the WARNING I get when entering my Password.
 +
I tried using https:// before the URL, but this fails.
 +
And I searched high and low for a Contact Us address, but there is none!
 +
Only way to get this message to you was to join as a temporary member, pending improved security.
 +
Please advise, before the Russians start messing with my account... {{unsigned|Temp Insecure‎}}
 +
 +
: Answered on the user's Talk page. [[User:Ahasuerus|Ahasuerus]] 19:35, 13 November 2018 (EST)
 +
 +
== Author names alphabetized ==
 +
 +
The way co-author names are displayed has been changed. In the past their order was random. Now they are displayed alphabetically based on their respective directory entries (typically family names) and the working names. If you come across any discrepancies, please post them here. [[User:Ahasuerus|Ahasuerus]] 20:33, 13 November 2018 (EST)
 +
: I don't understand "respective directory entries (typically family names) and the working names" and I may miss the point entirely.
 +
 +
: Is this true for Title records only?
 +
: Selected '''title listings for series [http://www.isfdb.org/cgi-bin/pe.cgi?33793 Gulliver's Travels]''':
 +
:* Variant: The Wonderful Voyages of Gulliver (1909) [as by Jonathan Swift and Edith L. Elias]
 +
:* Gulliver in Giantland (1907) [SF] by Jonathan Swift and Edith Robarts [only as by Edith Robarts and Jonathan Swift, D.D.]
 +
:* The Adventures of Gulliver (1954) [SF] by Jonathan Swift and E. E. Ellsworth
 +
:* Gulliver's Travels (1987) [SF] by Jonathan Swift and D. K. Swan and Michael West (II)
 +
: Those co-authors (commonly if not always, Swift and one or two who adapted or retold his work) are not listed alphabetically by family names. Spot check of author records shows correct directory entries such as "Swift" for Swift, D.D. and "West" for West (II).
 +
 +
: In the latter case, with three co-authors listed non-alphabetically, the '''bibliography for author [http://www.isfdb.org/cgi-bin/ea.cgi?166975 Michael West (II)]''' lists twice, as chapbook and short fiction: 
 +
:* Gulliver's Travels (1987) with Jonathan Swift and D. K. Swan
 +
: There West's two co-authors are out of sequence, same as in the title listing as displayed for the series. --[[User:Pwendt|Pwendt]]|[[User talk:Pwendt|talk]] 17:19, 29 November 2018 (EST)
 +
 +
:: It looks like there are still display bugs on Series and Summary pages. Thanks for reporting them! [[User:Ahasuerus|Ahasuerus]] 17:40, 29 November 2018 (EST)
 +
 +
::: Series and Summary pages have been changed to display author names alphabetically. If you come across any other bugs, please post them here. [[User:Ahasuerus|Ahasuerus]] 19:55, 9 December 2018 (EST)
 +
 +
== Title case cleanup - how? ==
 +
 +
(copied over from R&S): For the Dutch titles - and likely for other languages too - almost all titles hitherto entered in the DB follow the English capitalization rules. Now that we have made it clear language-specific capitalization rules are to be followed, titles need to be updated. What would be the best approach? Can we automate/manual excercise, cleanup reports,...? [[User:MagicUnk|MagicUnk]] 17:30, 14 November 2018 (EST)
 +
 +
: It is possible to create language-specific cleanup reports to look for titles with second/third/etc words capitalized. I expect that there will be a lot of false positives, so they'll need the "ignore" functionality from the get-go. [[User:Ahasuerus|Ahasuerus]] 18:29, 14 November 2018 (EST)
 +
 +
:: Would it work having a nightly job that automatically converts pub titles to the title title's case? Would be great not having to go through both title and pub titles. [[User:MagicUnk|MagicUnk]] 02:21, 15 November 2018 (EST)
 +
 +
::: Originally, there was no requirement for publication titles to match the titles of their respective "reference titles". In fact, we had somewhat different data entry rules for them. However, the rules have been converging over the last few years. We also have a cleanup report which looks for ''significant'' discrepancies between publication titles and their reference titles. At the rate things are going, we may want to consider enforcing consistency in the foreseeable future. For now, though, they can be different.
 +
 +
::: In addition, any kind of automated processing that changes ISFDB records without human supervision is potentially dangerous. We don't have anything like that in place at this time. [[User:Ahasuerus|Ahasuerus]] 09:56, 15 November 2018 (EST)
 +
 +
: As I recall, French and Russian titles have been using "sentence case" for a long time, so they should be in pretty good shape. I am not sure about other languages. I guess we could start by contacting the editors who have been working on major European languages to get a better idea of what the scope of the project(s) is likely to be. (And I see that Annie has already made a similar suggestion on the R&S page.) [[User:Ahasuerus|Ahasuerus]] 18:29, 14 November 2018 (EST)
 +
 +
:: From my OCLC cleanup and the language assignment one before that, French, German and Russian are indeed in a relatively good shape. Dutch is not looking too bad although it is a bit worse than the other 3 - there are a lot of titles with the wrong capitalization but from what I had seen a lot more that are added correctly. Spanish is a mixed bag (although I had seen a lot of updates going through), Italian is right there with it and Portuguese will give us a headache. The Western Slavic languages and Hungarian are mostly in the proper sentence case; so are Serbian, Romanian, Finnish and the Scandinavian ones. Bulgarian is clean :). Greek may be a bit of a challenge; the smaller ones should be easy enough to vet even if we go title by title. So as long as we decide on the rules, we may learn more.
 +
::: Re. Dutch not too bad: I'm afraid that's not true. I did a search, and for the first few hundred results, all needed correction to sentence case.
 +
 +
:::: The first hundred are stories with special characters and what's not which are relatively old records. It gets a lot better downstream - somewhere along the line Dutch editors started using the proper case. Although due to the volume of records, there may be more than expected... :) although looking a bit more into these, Dutch may need reclassification indeed - not sure which language I was thinking of. Oh well. That will be a very long project. [[User:Anniemod|Annie]] 02:43, 15 November 2018 (EST)
 +
 +
:: But point still stands - we need first to agree on the rules for a language before we start changing things in that language. [[User:Anniemod|Annie]] 18:54, 14 November 2018 (EST)
 +
:::: I'm confused?! Didn't we already agree on the case rule for Dutch? - true, not yet for punctuation but that shouldn't prevent us from cleaning up the ones that have no issue with punctuation. Or am I missing something here? [[User:MagicUnk|MagicUnk]] 02:12, 15 November 2018 (EST)
 +
 +
::::: You telling us that is the rules on a page is not an agreement - especially in a language we have multiple editors. Get the other editors to agree, we get closer. And when the official rules are changed, it is considered agreed on. [[User:Anniemod|Annie]] 02:43, 15 November 2018 (EST)
 +
 +
:::: Btw, I'm asking because I'm going through a lot of Dutch titles atm. [[User:MagicUnk|MagicUnk]] 02:18, 15 November 2018 (EST)
 +
 +
::::: Then leave a few messages around so we can get the rules locked down? [[User:Anniemod|Annie]] 02:43, 15 November 2018 (EST)
 +
 +
::: Yes, let's get those rules locked down. We have agreed to language-specific capitalization, but we haven't touched punctuation. Seems like we really ought to talk about punctuation before starting cleanup so as not to have to make multiple passes through the same records?
 +
 +
::: As for the Spanish data, there are quite a few Spanish records that were imported by machine in the early days of automated imports and were never cleaned up, and they're often in bad shape in every field. I fix them when I see them but I haven't had time to go after them systematically. --[[User:Vasha77|Vasha (cazadora de tildes)]] 19:02, 14 November 2018 (EST)
 +
 +
:::: Not just Spanish - a few more languages seem to have been imported the same way. Spanish is just the biggest offender. Plus we also have the translators to sort out so we can do 3 in 1 while editing for case, punctuation, subtitles and so on anyway. :)
 +
 +
:::: So [http://www.isfdb.org/wiki/index.php/Talk:Title_Regularization Title Regularization] invites everyone to contribute so we can start clearing languages. [[User:Anniemod|Annie]] 19:10, 14 November 2018 (EST)
 +
 +
== "0" Page Counts - Software Changes; Ebooks ==
 +
 +
While reading the code earlier today I finally recalled why we had special display logic for "0" page counts. Back in 2006-2009, when ebooks and audio books were not as common as they are today, we tried to come up with a standard for entering them. Both "0" and "unpaginated" were proposed as the preferred way of entering their page counts and the software was updated accordingly. That semi-standard was abandoned years ago and is no longer mentioned in Help.
 +
 +
Based on my findings, I have updated the software not to do any kind of special processing for "0" and "unpaginated" page counts. As of 15 minutes ago, the software simply displays whatever is in the "Pages" field, assuming that it's not empty. I have also removed "0" from the page count fields of all ebooks. Fewer than 2% were affected.
 +
 +
This leaves us with 119 webzines and 9 "other" publications which still use "0" as their page count. I left them alone for now in case anybody wants to look into them. [[User:Ahasuerus|Ahasuerus]] 17:52, 14 November 2018 (EST)
 +
 +
: I will check the "other" ones and update as necessarily. I think that getting the webzines cleaned should not be a problem - they are not different either...
 +
 +
: Any chance of adding the nice yellow warning when someone tries to add pages on non-text material? [[User:Anniemod|Annie]] 17:58, 14 November 2018 (EST)
 +
 +
:: Potential problem: theoretically ebooks don't have pages; however, PDFs, which do have pages, are lumped in with other ebooks --[[User:Vasha77|Vasha (cazadora de tildes)]] 18:19, 14 November 2018 (EST)
 +
 +
::: We can exclude ebooks for now - I am more concerned about audiobooks and the like at the moment. However - even for PDFs, our rules say not to record page. So... technically those should be empty. If we want to separate the PDFs, we need a separate discussion. But that opens the Pandora box of the old Fictionwise titles (remember those?) that you could download in more than one format, one of them being PDF - and recording all formats as separate books did not make sense. Thinking about that, there are a few publishers like that nowadays as well... [[User:Anniemod|Annie]] 18:26, 14 November 2018 (EST)
 +
 +
:::: Although I unfortunately can't recall exactly what it was, I know I saw one book which was offered in PDF format with illustrations or ePub/mobi without illustrations. Really, PDFs aren't quite the same thing as other ebooks (more similar to a printed book in some ways). But I don't want to start a discussion about that on top of the other 20 ongoing discussions. --[[User:Vasha77|Vasha (cazadora de tildes)]] 18:43, 14 November 2018 (EST)
 +
 +
::::: For some of them. But for a lot of publishers, they are basically the same - just a new format... When there are illustrations in one and not in the other, they should be separate records anyway. Although the current e-book formats support images so... the differences will be less and less. And converting between the formats is trivial. I do not dispute that there are e-books that have pages (from scanned copies of paper books to proper PDFs), we need to decide what we want to do about them before we start adding page numbers (as the current rules do not make a difference). [[User:Anniemod|Annie]] 18:59, 14 November 2018 (EST)
 +
 +
:::::: Keep in mind that a yellow warning is just that -- a warning that tells the approving moderator to do more digging. For example, Fixer submissions without a publisher generate warnings, but in many cases they are OK "as is". [[User:Ahasuerus|Ahasuerus]] 10:00, 15 November 2018 (EST)
 +
 +
== SFBC question ==
 +
 +
I picked up an SFBC copy of ''Rift in the Sky''. It has an SFBC number, 1275245, on the back part of the jacket.
 +
ISFDB has {{p|294490|this record}} for DAW Books / SFBC which says "Catalog ID: 08-6848" and "Catalog #/price from the SFBC flyer."
 +
 +
My question is - do SFBC fliers, at least in 2009, have the number that's printed on the jacket?  I'm wondering if I should edit the existing record, change the catalog #, and update the notes that that the catalog # in the SFBC flier is 08-6848 and that the publication states 1275245. Or should I create a new DAW Books / SFBC publication record for Catalog # 1275245.  --[[User talk:Marc Kupper|Marc Kupper]] 02:54, 15 November 2018 (EST)
 +
: [http://www.isfdb.org/wiki/index.php/Publisher:Science_Fiction_Book_Club We have some data here]. Just adding some notes - I did some digging when we started the "move the ID project for SFBC". My understanding is that 08-6848 should go back down in the notes (even if it is not your book) as it is catalog number and not an ID number (which is what we put in the catalog field). Cannot help much more I am afraid but I am sure someone will be along with more data... [[User:Anniemod|Annie]] 03:03, 15 November 2018 (EST)
 +
 +
::I believe the printed 1275245 corresponds to the SFBC catalog number 12-75245, which I then think means it's a different edition from that of the existing record.  --[[User:MartyD|MartyD]] 07:01, 15 November 2018 (EST)
 +
 +
::: I do not think that the conversion is that clear cut - ID 1353404 has catalog ID 13-534046 for example and not the expected 13-53404 - the catalog always adds one more number at the end... But I would agree that this looks like a different book though... [[User:Anniemod|Annie]] 14:59, 15 November 2018 (EST)
 +
 +
:::: Thank you.  I'll go with a new record as the numbers are very different. --[[User talk:Marc Kupper|Marc Kupper]] 02:16, 16 November 2018 (EST)
 +
 +
== The Witch of Blackbird Pond ==
 +
 +
Is [http://www.isfdb.org/cgi-bin/title.cgi?32473 this book] really eligible for being here? As far as I can tell, it's not actually fantasy at all. Rather, it's historical fiction that has multiple people being accused of being a witch in early New England. We have quite a few publications of it listed. Thoughts? ···[[User:Nihonjoe|<font color="darkgreen">日本穣</font>]] · <small>[[Special:Contributions/Nihonjoe|<font color="blue">投稿</font>]] · [[User talk:Nihonjoe|Talk to Nihonjoe]]</small> 14:47, 15 November 2018 (EST)
 +
: All 3 verifiers are active so why don't we check if one (or more) of them read the book and can tell us if there is anything speculative? [[User:Anniemod|Annie]] 14:56, 15 November 2018 (EST)
 +
 +
::Invited. I read it years ago, and I don't remember any speculative fiction content (as defined here) at all. It's just historical fiction. No fantasy, science fiction, or horror at all. ···[[User:Nihonjoe|<font color="darkgreen">日本穣</font>]] · <small>[[Special:Contributions/Nihonjoe|<font color="blue">投稿</font>]] · [[User talk:Nihonjoe|Talk to Nihonjoe]]</small> 15:06, 15 November 2018 (EST)
 +
 +
::: Ah, did not realize you read it. Let's see if someone else has an opinion (as it is a children book, I wonder if we are not looking at fairy tales kinda situation?). If it is indeed not speculative, I agree that it needs zapping. [[User:Anniemod|Annie]] 15:20, 15 November 2018 (EST)
 +
 +
::::You can read the summary [https://en.wikipedia.org/wiki/The_Witch_of_Blackbird_Pond#Plot_summary over here], too. ···[[User:Nihonjoe|<font color="darkgreen">日本穣</font>]] · <small>[[Special:Contributions/Nihonjoe|<font color="blue">投稿</font>]] · [[User talk:Nihonjoe|Talk to Nihonjoe]]</small> 16:09, 15 November 2018 (EST)
 +
 +
::::: Yeah, I did not see anything there but then half the magical realism sounds non-speculative to me as well (even after I read it) :) [[User:Anniemod|Annie]] 16:24, 15 November 2018 (EST)
 +
 +
:::::: I verified it because I had it, and because it was extensively listed on this site.  I've been meaning to read it since I was knee-high to a grasshopper, but I still haven't gotten around to it.  I'm assuming that it was added back in the early days of this site, and then people just continued to build on this submission.  It was a popular book in its day, but to get the real deal on the content of this book you'll probably have to ask some other geriatric case besides me, who has actually read the book.  If it has to go the way of the dodo, then so be it.  Too bad you can't ask the general contributors of this site.  Maybe on the "help" page. [[User:MLB|MLB]] 17:02, 15 November 2018 (EST)
 +
 +
::::::: Yeah, I have read it (a long time ago) and don't remember anything speculative. --[[User:Vasha77|Vasha (cazadora de tildes)]] 18:32, 15 November 2018 (EST)
 +
 +
:Vasha's right, the "witch" angle is the xenophobia and superstition of the New Englanders and their persecution of the title character. [[User:Ofearna|Ofearna]] 23:14, 16 November 2018 (EST)
 +
 +
(unindent) So anyone opposing the deletion of the title (and all the publications containing it)? [[User:Anniemod|Annie]] 23:40, 16 November 2018 (EST)
 +
 +
: I have no objection. It might be nice to copy-and-paste the verified pubs' data to their respective verifiers' Talk pages for reference purposes. [[User:Ahasuerus|Ahasuerus]] 10:22, 17 November 2018 (EST)
 +
 +
:: Delete away. That book was in a collection I bought, not a keeper or a read-me. Only entered because it was already listed. --[[User:Bluesman|~ Bill, Bluesman]] 13:50, 18 November 2018 (EST)
 +
 +
:Deletion has been completed. Those who had verified any of them have the publication information on their talk pages. ···[[User:Nihonjoe|<font color="darkgreen">日本穣</font>]] · <small>[[Special:Contributions/Nihonjoe|<font color="blue">投稿</font>]] · [[User talk:Nihonjoe|Talk to Nihonjoe]]</small> 13:58, 19 November 2018 (EST)
 +
 +
== Title checkboxes now appear on the same line ==
 +
 +
As per [[ISFDB:Community_Portal#Reorganizing_data-entry_fields:_how_difficult.3F|this discussion]],  title checkboxes now appear on the same line. The change affects all New Publication edit forms as well as Edit Title. Let's see if the new layout is an improvement.
 +
 +
P.S. You may need to do a full page reload (Control-F5 in most browsers) for everything to display correctly. [[User:Ahasuerus|Ahasuerus]] 18:56, 15 November 2018 (EST)
 +
 +
: They should be a little farther apart: the labels need to be more visually separated from one another. --[[User:Vasha77|Vasha (cazadora de tildes)]] 19:24, 15 November 2018 (EST)
 +
 +
:: Good point; I have made the changes. Could you please do a full page reload to see if the spacing looks better? [[User:Ahasuerus|Ahasuerus]] 20:32, 15 November 2018 (EST)
 +
 +
::: Yes, that's an improvement. --[[User:Vasha77|Vasha (cazadora de tildes)]] 20:37, 15 November 2018 (EST)
 +
 +
: Can we do something about the focus on these fields? At the moment it jumps from Content to Synopsis when you tab through it, skipping the checkboxes (both on addPub and editPub). When I am not working on a touchscreen, not needing to use the mouse to navigate the page is pretty useful. These are also the only ones that are skipped :) [[User:Anniemod|Annie]] 20:41, 15 November 2018 (EST)
 +
 +
:: Sure, let me take a look. [[User:Ahasuerus|Ahasuerus]] 20:58, 15 November 2018 (EST)
 +
 +
::: Done. [[User:Ahasuerus|Ahasuerus]] 21:11, 15 November 2018 (EST)
 +
 +
:::: You are getting faster and faster in fixing these. Thanks! [[User:Anniemod|Annie]] 21:20, 15 November 2018 (EST)
 +
 +
== Google search proposal ==
 +
 +
(copied from above) Re: lower case versions of non-Latin values, I think it will only get us so far whether we enter them in the existing Transliterated Values fields or in the requested new field. Adding "павел вежинов" to "Павел Вежинов" won't help users who type "ПАВЕЛ ВЕЖИНОВ". Without full Unicode support, it will remain a band-aid. [[User:Ahasuerus|Ahasuerus]] 17:05, 13 November 2018 (EST)
 +
 +
: (moved from above) : No, it won't help the guys that write in caps only but combined with a note on the search result page that mentions that if you are using non-standard Latin characters, you should search in small letters, it will be a better band-aid than anything else we can come up with for the short term... I've never called it a solution - just a short term way to make the DB somewhat usable. [[User:Anniemod|Annie]] 17:43, 13 November 2018 (EST)
 +
 +
:: Well, if the proposed addition of all-lower case versions of titles/names/etc requires an Advanced Search note to be fully functional, wouldn't it be easier to display an Advanced Search note about the need to use the exact case for non-Latin-1 characters? [[User:Ahasuerus|Ahasuerus]] 19:25, 14 November 2018 (EST)
 +
 +
::: Yes but that will require you to know the capitalization rules of the language. Which will be ok for speakers of the language; not as good for a researcher that can read the script but has a shaky idea of the language... And then you have Легуин/ Ле Гуин. When we have all the titles, finding either will work but if you had never seen her name written the other way, that "Guin" will trip you. I am not saying that is a perfect solution - away from that. Just trying to find a workaround... If everyone thinks that this will be an overkill, then I am fine with just adding a note to ask "according to language rules" with a link to the new pages we are building. Either will be better than now :)[[User:Anniemod|Annie]] 19:34, 14 November 2018 (EST)
 +
 +
:::: I had been thinking on that. While this will make our search a bit more manageable, it is really a bandaid. And considering the Russian titles, it will take a long time to update all of them. And a user that is not used to the DB won't really do a second search this way... So... why not use google to help us (someone already mentioned it above - I am just slowly warming up to it). Unlike us, it speaks languages and actually can do some level of autocorrect (which is helpful if you are not strong in a language). So... why not modify the search result page and just give the ability to search in google (with the site name added already and so on. So the built-in search is still there for direct matches but we have a viable way for someone to find something if they do not spell exactly as expected. [[User:Anniemod|Annie]] 22:02, 15 November 2018 (EST)
 +
 +
::::: Yes, it was originally proposed by JLaTondre. I can think of a few ways to leverage Google Search:
 +
 +
:::::# Add "Google Search" as a new section within Advanced Search [original proposal]
 +
:::::# Add a "Google Search" checkbox to the standard search box, which will alter the behavior of the search logic, redirecting it to Google [my original response to the proposal]
 +
:::::# If a search (regular or Advanced) fails, display the standard "No matching records found" message, then display a Google Search button with an explanatory note. If clicked, the button will execute a Google Search for the entered value and the appropriate search type.
 +
:::::# In addition to option 3 immediately above, even if a search succeeds, display the Google Search button in addition to displaying the standard results table.
 +
 +
::::: My current thinking is that options 3 and arguably 4 may be our best bet. They wouldn't affect the current workflow and would provide additional functionality without interrupting anything.
 +
 +
::::: The only partial failure scenario (that I can think of) would be the regular ISFDB search engine finding only one matching record and automatically redirecting the user to that record's page. That's what we typically want to happen except when we have other "imprecise" matches which our search logic doesn't find. Still, it appears to be a good compromise. [[User:Ahasuerus|Ahasuerus]] 23:18, 15 November 2018 (EST)
 +
 +
:::::: This is an excellent thought. I like your proposal 3. --[[User:Vasha77|Vasha (cazadora de tildes)]] 01:01, 16 November 2018 (EST)
 +
 +
::::::: I'd like to see the link as well when there are results - the more titles and authors we get, the more often we will be getting false positives (aka something matching but not you are not looking for...). Add also a checkbox in Advanced Search that allows the search to be done via Google instead of our search (so you do not need to fail a search first) and we should be all set. [[User:Anniemod|Annie]] 01:08, 16 November 2018 (EST)
 +
 +
:::::::: (After sleeping on it) Modifying Advanced Search to work with Google may be tricky. We support a lot of different permutations ("Reviewed Author is not exactly Павел Вежинов") which may not directly translate to Google queries. We'll have to review Google's documentation to see which parts can be approximated. It may be best to start with our regular Search, which should be much easier to implement. [[User:Ahasuerus|Ahasuerus]] 09:06, 16 November 2018 (EST)
 +
 +
::::::::: I think that my statement went away from me :) I was thinking more in the line of "where to put it so I do not need to fail a search first", the Advanced Search sounded as a nice place and I ran with it. I would agree that putting the whole advanced search out is not as easy. [[User:Anniemod|Annie]] 13:46, 16 November 2018 (EST)
 +
 +
:::::::::Google is a page search engine, not a database field search engine. They are inherently different workflows. I would not do #3 & #4 with advanced search results. There is not a way to duplicate the field logic and the results could be confusing to users. I'm not even sure I would do it with regular search. I was envisioning adding a new section to the Advanced Search page, labeling it Google Search, providing a single pull down to pick the page type (All, Title, Author, etc.) and a single search box for people to enter terms. Could add some explanations regarding quotes for phrases and negatives for not. Why make it complicated? Most people are familiar with search engines already. Yes, it's more focused at the experienced ISFDB user who understands the limitations of the ISFDB search and why you'd want to use it. But I'm not sure #3 & #4 on the basic search help users who aren't. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 10:12, 17 November 2018 (EST)
 +
 +
:::::::::: I think the main reason to add a "Google Search" button when the regular search logic finds no matches is to give less experienced users -- who may not realize that our software doesn't support approximate searches, what Advanced Search options are available, etc -- a simple way to recover. Currently, if they enter "павел вежинов" instead of "Павел Вежинов", the software tells them that we don't know anything about "павел вежинов" and that's it. The proposed "Google Search" button would give them the ability to retry the search near instantaneously. Of course, we'd need to add an explanatory note.
 +
 +
:::::::::: That said, I can see the value in creating a separate "Google Search" section within Advanced Search. I expect that only more experienced users will know about it, but hey, experienced users are people too!
 +
 +
:::::::::: It should be fairly easy to implement and tweak as needed, so I have created {{FR|1226}}. I am out of sorts at the moment, so it may be some time before I get to it. [[User:Ahasuerus|Ahasuerus]] 20:43, 17 November 2018 (EST)
 +
 +
== New Template: Narrator ==
 +
 +
A new template, "Narrator", has been created. Help has been updated. [[User:Ahasuerus|Ahasuerus]] 10:44, 16 November 2018 (EST)
 +
 +
== Haldeman's 'All My Sins Remembered' series ==
 +
 +
I propose changing the name of Joe Haldeman's series that we currently have under the name of [http://www.isfdb.org/cgi-bin/pe.cgi?25200 'All My Sins Remembered'] to 'Confederación'. There are other 'Confederación' stories that do not appear in the 'All My Sins...' collection, such as the first four stories in [http://www.isfdb.org/cgi-bin/pl.cgi?53319 Vietnam and Other Alien Worlds]. They're usually/generally referred to as Confederación stories, also by Haldeman himself. Feedback appreciated! [[User:PeteYoung|PeteYoung]] 02:40, 18 November 2018 (EST)
 +
 +
:Yes, I'm all for it. It's plain better than to name it after one of its titles. [[User:Stonecreek|Stonecreek]] 09:52, 20 November 2018 (EST)
 +
 +
== [http://www.isfdb.org/cgi-bin/title.cgi?21819 Midsummer Century] by James Blish and [http://www.isfdb.org/cgi-bin/title.cgi?5335 Planet of No Return] by Poul Anderson ==
 +
 +
With just around 100 pages of text as a stand-alone publication and 95 pp. within the same-named collection this has to be correctly defined as a NOVELLA. If there's no objection, I'll merge it with the existing SHORTFICTION. [[User:Stonecreek|Stonecreek]] 09:51, 20 November 2018 (EST)
 +
:The title record you linked to says:
 +
::Expansion of the version published in ''Magazine of Fantasy and Science Fiction'' in April 1972.
 +
: Have you done a word count to see if it's under 40,000 words? There are three hardcover editions.<sup>[http://www.isfdb.org/cgi-bin/pl.cgi?192965 1] [http://www.isfdb.org/cgi-bin/pl.cgi?201393 2] [http://www.isfdb.org/cgi-bin/pl.cgi?201397 3]</sup>. The word count, not the page count, is how the stories get classified.
 +
: The main support for novella is that it's also part of a collection, {{t|38198|Midsummer Century}}, meaning at present we have a collection that contains a novel plus two other novelettes. --[[User talk:Marc Kupper|Marc Kupper]] 23:14, 20 November 2018 (EST)
 +
 +
::I've done a word count for the German translation: it comes round 34,000 words. It would be good if it's remembered by whom the note was added, if it's based on an actual word count, or was put there because the publisher called the book publication a novel (anyway, even an expansion doesn't have to mean that it was expanded to more than 40,000 words). And the very most examples of publications in book form have shown that there have to be at least 120 pages of text to qualify it as a novel (sometimes even 140 pages are still a novella). [[User:Stonecreek|Stonecreek]] 23:47, 20 November 2018 (EST)
 +
 +
The same transformation from NOVEL to SHORTFICTION (novella) seems to hold for the title by Poul Anderson. Are there other (higher) word counts? [[User:Stonecreek|Stonecreek]] 15:05, 22 November 2018 (EST)
 +
 +
And also to Anderson's ''The War of Two Worlds'', which is even shorter than ''Planet of No Return'', [http://www.isfdb.org/cgi-bin/pl.cgi?50556 here]. I habe changed both to shortfiction (novella). [[User:Stonecreek|Stonecreek]] 10:41, 30 November 2018 (EST)
 +
 +
== Canonical name change ==
 +
 +
The writer formerly known as [http://www.isfdb.org/cgi-bin/ea.cgi?214254 Joseph Allen Hill] is now going by [http://www.isfdb.org/cgi-bin/ea.cgi?273163 Violet Allen] and has had 2 stories published and an award nomination with the latter name. I am going to be changing her canonical name tomorrow. --[[User:Vasha77|Vasha (cazadora de tildes)]] 18:58, 24 November 2018 (EST)
 +
:I don't think we reached [[Rules_and_standards_discussions#Canonical_names_for_transgender_authors_-_Consensus.3F|consensus]] to do this.  Shouldn't the canonical name be Hill with 11 titles published instead of Allen with only 3? --Ron ~ [[User:Rtrace|Rtrace]]<sup>[[User talk:Rtrace|Talk]]</sup> 09:03, 25 November 2018 (EST)
 +
 +
:: That's right. No consensus was reached, so the data entry rules were not changed. [[Template:AuthorFields:CanonicalName]] still says:
 +
 +
::* the canonical name is the most recognized name for that author within the genre
 +
 +
:: The only thing that changed based on that discussion was how the software treats alternative names. They used to be called "pseudonyms", now they are called "alternative names". [[User:Ahasuerus|Ahasuerus]] 10:18, 25 November 2018 (EST)
 +
 +
::: In the meanwhile, we are still behaving abominably toward transgender authors... It's unacceptable. We need to make the policy change. --[[User:Vasha77|Vasha (cazadora de tildes)]] 13:23, 25 November 2018 (EST)
 +
 +
:::: Perhaps at some point we'll be able to reach a new consensus re: this issue, at which point the policy will be changed. Until it happens, moderators are expected to enforce the current policy. [[User:Ahasuerus|Ahasuerus]] 14:34, 25 November 2018 (EST)
 +
 +
::::: The fact that moderators (as a community) can't summon up basic courtesy toward authors doesn't say very good things about the culture here, at all. This is an instance where indifference and inaction are affronts. --[[User:Vasha77|Vasha (cazadora de tildes)]] 15:18, 25 November 2018 (EST)
 +
 +
:::::: Except that this has nothing to do with courtesy or someone's gender, religion, changed marital status or whatever. We are a bibliographical database - not a biographical one. Our main source are the books - anything else is just supporting data to help us make the DB better. Which is why our definition of a canonical name is not "the name the author prefers or uses now" but "the most recognized" and by extension, "the one that is on most books". I respect the choice of someone to start using a new name for whatever reason but if most of their books still carry the old name, that old name is still the bibliographical name under which people recognize them. Add a note on the author page that as of this date they are using a new name if you want; keep an eye on their output and add anything new until the balance start shifting - but until the majority of books/stories one can read carry the old name, most people will look under that name.
 +
 +
:::::: Now... when we opened the DB for webzines and other web sources, that may change the equation a bit - because now the name on the record may change - and we may need to have a discussion around that. But this is not the case here. So let's not throw around accusation of lack of respect and what's not - the field does not record what you want it to - and if you want that to change, start a discussion. A bibliographical one if possible. [[User:Anniemod|Annie]] 17:21, 25 November 2018 (EST)
 +
 +
::::::: Blaming lack of respect on "simply following bilbliographic principles" is not a way to get out of responsibility. In fact, it's a classic ploy by people who have the power to chose public naming practices; we must use our power better. Be an ally for transgender people and create a new rule for canonical names that accepts and validates their identity. We would not be overriding any bibliographic data that way. People who look up the old name would simply be redirected to the new one. --[[User:Vasha77|Vasha (cazadora de tildes)]] 17:29, 25 November 2018 (EST)
 +
 +
:::::::: So in your view a name change is important only when it happens because someone is transgender but not when someone changes their religion or marital status or just feels like it? Why would one require validating while the rest do not? How we record one's name does not depend on their gender, nationality, race, eye color, a change in any of them or anything else like that. We cannot have one rule for someone changing a name because of getting their gender aligned to their identity and a different one for a religion change (for example). If we decide to change the rules, it should not be because of a specific type of a change. And that change needs to go through changing what "canonical name" means in the DB - because it sounds like that is what you have an issue with (and you are conflating that with respecting people and so on). Are we still talking about books and their records here or did that conversation drifted somewhere again?
 +
 +
:::::::: Yes, transgender people do need all the support they can get. So do a lot of other groups. But making special rules for that is not the way to go - not if you are really looking for normalization and respect. Start a new discussion about changing the meaning of "canonical name" to "preferred/currently used", come up with a plan on how we will follow changes (because otherwise we will end up with a lot of "you changed theirs, why not mine" kind of situations and we can change the rules. Or do we only care when we hear about the change? [[User:Anniemod|Annie]] 17:51, 25 November 2018 (EST)
 +
 +
::::::::: Reopening a Rules and Standards issue on the Community Portal would only splinter the discussion, so I will limit my comments to the following.
 +
 +
::::::::: Over the years, we have seen a number of requests to change our bibliographic practices based on their impact on publishers and authors. For example, at one point a user stopped by and argued that some of our practices were harming small presses by making major publishers unduly prominent. At another point an author was unhappy about the inclusion of her works and told us that she never asked us to list them.
 +
 +
::::::::: To the best of my recollection, none of these arguments have been accepted. We are a bibliographic project. Our primary goal is to create comprehensive and accurate bibliographies. We are not in the business of allying with or validating anyone. We try not to let our personal esthetic, political, national, ideological, etc preferences determine the scope or the policy. If we did, the project would be harmed because we all have different preferences. [[User:Ahasuerus|Ahasuerus]] 18:34, 25 November 2018 (EST)
 +
 +
== "Black Helicopters" ==
 +
 +
Opinions wanted: should the 2018 version of Caitlín R. Kiernan's [http://www.isfdb.org/cgi-bin/title.cgi?1756681 Black Helicopters] have a separate record from the 2013 version? It sounds to me like it should, based on it being described as "expanded and completed" (as a weaker indication, Tor.com doesn't publish reprints so they must have thought this work was new in some sense). However, I've only seen the new version and would like to hear from someone who's seen both and can compare. --[[User:Vasha77|Vasha (cazadora de tildes)]] 15:15, 28 November 2018 (EST)
 +
 +
: Sounds similar to Nina Allan's "The Race" case: [http://www.isfdb.org/cgi-bin/title.cgi?1768867 here] - the second edition added a new section which not only changes how the novel finishes (and shifts the understanding of some earlier sections) but also increases the size significantly. I would think we should have a variant for such significant changes (or even separate titles) but none of the two concepts match exactly (although if an abridgement is a variant, why not expansion?). Anyway... no real idea about what we should do here - just thinking aloud and throwing another similar case in the pot. :) [[User:Anniemod|Annie]] 15:26, 28 November 2018 (EST)
 +
 +
:: Typically, "rewrites" and "major changes" get their own titles while "revisions" and "minor changes" are documented in Notes. Unfortunately, determining the scope of the changes can be challenging. In this case my first reaction was "The Subterranean Press edition was only 89 pages while the Tor.com edition is 196 pages, so surely it merits a separate title record." However, Tor.com has been known to make novellas (<40K words) look like novels, so their page count doesn't necessarily tell us much. [[User:Ahasuerus|Ahasuerus]] 16:46, 28 November 2018 (EST)
 +
 +
:::As moderator, I 'voted' for keeping the title for both incarnations: the question for me was if there's a whole different story told, or if it's another title type (novel). It seemed both were not the case. So, the difference we know of should be covered in the title's note. [[User:Stonecreek|Stonecreek]] 04:18, 29 November 2018 (EST)
 +
 +
== Tasha Suri ==
 +
 +
Currently [http://www.isfdb.org/cgi-bin/ea.cgi?259075 Natasha Suri] is the canonical name with Tasha Suri as an alternate, but I think it should be the other way around. "Tasha" is on the cover of a novel which makes it more prominent than the other which is just used for one short story; plus all her web presence is using the name on the novel. --[[User:Vasha77|Vasha (cazadora de tildes)]] 13:57, 29 November 2018 (EST)
 +
 +
:Okay when there's a second novel (or of another title type) with her name on the cover. [[User:Stonecreek|Stonecreek]] 14:03, 29 November 2018 (EST)
 +
 +
:: Sorry, that makes no sense. You can't argue that the "best-known" name should be canonical and then not use "Tasha" which is what this author is called in 98 out of 100 references on the web, plus the novel which is a much better-known publication than the story. --[[User:Vasha77|Vasha (cazadora de tildes)]] 14:09, 29 November 2018 (EST)
 +
 +
::: When dealing with authors who have used multiple names, I usually give more "weight" to novels than to stories. OTOH, it can get tricky if a story is much better known than a novel. For example, {{A|Harry Stephen Keeler}} is probably best remembered for his story "John Jones' Dollar" even though a number of his once popular novels also contained speculative elements. To make things even more complicated, Keeler has experienced something of a revival over the last 20 years. With many of his novels now in print, it's possible that they have once again become as well known as "John Jones' Dollar". Luckily, he only used one name, so it's not an issue for us.
 +
 +
::: In this case I would use the "novel name" and keep an eye on the author. [[User:Ahasuerus|Ahasuerus]] 15:01, 29 November 2018 (EST)
 +
 +
:::: OK, I will swap the names, then. --[[User:Vasha77|Vasha (cazadora de tildes)]] 10:28, 30 November 2018 (EST)
 +
 +
== Searching books in a specific language ==
 +
 +
Does anyone have a trick on how to find all the books in a specific language (or all books filtered based on an author or any other element)? Not the titles but the publications - especially in cases where the filter is shared between languages or not always there for that language? I know that I can get to that through searching all titles in that language and grabbing all book under each title (and I know how to do that through the DB) but we do not have a way via Advanced Search, right?
 +
 +
If that is indeed so, how about adding that as an option (where a pub is in a language when its reference title is in that language OR when there is a title inside in that language - whatever makes more sense (dual language books are the ones that will be different based on what we decide; for the rest the results will be the same. [[User:Anniemod|Annie]] 18:15, 29 November 2018 (EST)
 +
 +
: Re: "all books filtered based on an author or any other element", the Advanced Publication Search lets you specify the ''pub'' author's name, date/place of birth etc. For example, [http://www.isfdb.org/cgi-bin/adv_search_results.cgi?USE_1=author_canonical&OPERATOR_1=exact&TERM_1=%26%231055%3B%26%231072%3B%26%231074%3B%26%231077%3B%26%231083%3B+%26%231042%3B%26%231077%3B%26%231078%3B%26%231080%3B%26%231085%3B%26%231086%3B%26%231074%3B&CONJUNCTION_1=AND&USE_2=pub_title&OPERATOR_2=exact&TERM_2=&CONJUNCTION_2=AND&USE_3=pub_title&OPERATOR_3=exact&TERM_3=&ORDERBY=pub_title&START=0&TYPE=Publication this search] gives you a list of books by Павел Вежинов. [[User:Ahasuerus|Ahasuerus]] 09:53, 30 November 2018 (EST)
 +
 +
:: Yes but if the name is the same in more than one language, you get too many results - I am looking for the language being an available filter. With some languages there are filters that may help (if I makes sure that all Bulgarian books have prices even when they are just "Leva" or something, I can use that as a filter. But not all languages have single currencies or anything else that will make them unique. [[User:Anniemod|Annie]] 10:26, 30 November 2018 (EST)
 +
 +
: "Books [i.e. publications] in a specific language" would be tricky because the search logic would have to find the "reference title" for each publication and then look up its language. Reference titles are not straightforward: magazines and fanzines use "EDITOR" while other publication types have matching title types. A couple of existing cleanup reports check pubs against their reference titles, but the queries are complex and they take a long time to run. I am not sure it would be feasible to add this functionality to the Advanced Publication Search. [[User:Ahasuerus|Ahasuerus]] 09:53, 30 November 2018 (EST)
 +
 +
:: How about "any title in the language" inside of the publication? Or any non-art title? I know that the DB is not set for that but... that's a pretty common question. [[User:Anniemod|Annie]] 10:26, 30 November 2018 (EST)
 +
 +
::: I have created {{FR|1229}} to document the desired functionality, but I expect that it will require a fair amount of tweaking and research. [[User:Ahasuerus|Ahasuerus]] 13:04, 30 November 2018 (EST)
 +
 +
:::: Thanks! I will look some more to see what else I can figure out as a possible way  to filter in the meantime. [[User:Anniemod|Annie]] 14:34, 30 November 2018 (EST)
 +
 +
::::Maybe this could be a nightly report (or weekly, if nightly would be too much) that's created, in order to preserve server resources. ···[[User:Nihonjoe|<font color="darkgreen">日本穣</font>]] · <small>[[Special:Contributions/Nihonjoe|<font color="blue">投稿</font>]] · [[User talk:Nihonjoe|Talk to Nihonjoe]]</small> 14:43, 30 November 2018 (EST)
 +
 +
::::: A report that lists all the books in all languages won't be very useful though and will frankly be an overkill - I am not looking for numbers but for data (which can be filtered)... [[User:Anniemod|Annie]] 14:48, 30 November 2018 (EST)
 +
::::::I meant reports for each language (other than English). If the big ones were spread out across the days of the week so each one was only run once a week, the small ones could be fit in wherever. This way, the information is available, and it doesn't use inordinate amounts of resources whenever someone tries to find them. They could be listed on a separate page like the cleanup reports. ···[[User:Nihonjoe|<font color="darkgreen">日本穣</font>]] · <small>[[Special:Contributions/Nihonjoe|<font color="blue">投稿</font>]] · [[User talk:Nihonjoe|Talk to Nihonjoe]]</small> 17:34, 30 November 2018 (EST)
 +
 +
:::::: Even for one language - that list won't be much better than what I can get going via the titles search for example with a few separate searches (or directly from the DB) - if you cannot filter it, it is just a list that does not help much but takes a long time to generate (and I really do not want to add another heavy report/computation at 1 am - we are doing much better now but the server is still very sluggish while the jobs run). I know where you are going with you but... it won't really do what I would expect it to. I know the limitation of our DB, I know it won't be trivial - just had to ask in case I was missing an obvious way. [[User:Anniemod|Annie]] 18:43, 30 November 2018 (EST)
 +
 +
== Lemuel Gulliver and his famous Travels ==
 +
 +
Is there a principle by which we sometimes parse a title page so that <u>"by Lemuel Gulliver", for instance, is part of the title of a work</u> rather than its author credit?
 +
 +
For the first edition of ''Gulliver's Travels'', and some others, we have T{{t|1719519}}
 +
: Title: Travels Into Several Remote Nations of the World in Four Parts by Lemuel Gulliver 
 +
: Author: Jonathan Swift
 +
Glasgow University Library "Book of the Month" January 2006 [http://special.lib.gla.ac.uk/exhibns/month/jan2006.html], which we link from the title record, displays the original title page of volume one, which shows (quote including horizontal lines):
 +
: Travels into several Remote Nations of the World.
 +
----
 +
: In Four Parts.
 +
----
 +
: By Lemuel Gulliver, First a Surgeon, and then a Captain of several Ships.
 +
----
 +
: Vol. I.
 +
 +
At the moment we have only one author by the name "Lemuel Gulliver", credited with only two works: [http://www.isfdb.org/cgi-bin/adv_search_results.cgi?START=0&TYPE=Title&exact=128393&ORDERBY=title_title by Lemuel Gulliver]. One is the spurious volume three, a 1727 sequel by unknown. The other is an 1812 variant title of Swift's work, with one 1812 publication only. Its [https://hdl.handle.net/2027/mdp.39015070295814?urlappend=%3Bseq=55 internal title page] (viewed at HathiTrust) displays "In Four Parts" below the credit to Lemuel Gulliver, First a Surgeon, etc. 
 +
: P.S. There "into" should be "Into", or vice versa for some the first edition variant titles.
 +
--[[User:Pwendt|Pwendt]]|[[User talk:Pwendt|talk]] 18:37, 29 November 2018 (EST)
 +
 +
:: Well, it should depend on naming Swift as the author also on the title page (which does the Glasgow University Library, for example). [[User:Stonecreek|Stonecreek]] 00:10, 30 November 2018 (EST)
 +
 +
:::Am I misreading the title page cited?  Neither the link to the Glasgow University image of the title page nor any of our title page images of {{t|1719519}} list Swift.  Bleiler's '' Science Fiction: The Early Years'' describes the 1726 edition as "published anonymously".  Bleiler78 lists it as published as by Lemuel Gulliver.  Clearly that title record should either be uncredited with "by Lemuel Gulliver" in the title or the name should be removed from the title and these should be under the Lemuel Gulliver alternate name.  If I were entering these from scratch I would take the latter approach.  --Ron ~ [[User:Rtrace|Rtrace]]<sup>[[User talk:Rtrace|Talk]]</sup> 21:01, 30 November 2018 (EST)
 +
::::I'm with Ron here: consider what you would do if you had no foreknowledge. Then looking at the title page Gulliver is the author, and "by Lemuel Gulliver" not part of the title.
 +
::::Additionally, Gulliver being an alernate name to unknown must be removed and changed into alternate of Swift. [[User:MagicUnk|MagicUnk]] 03:20, 1 December 2018 (EST)
 +
:::::The two parent names for Lemuel Gulliver is correct.  {{t|1048233}} is not by Swift and the actual author is not know.  This situation sometimes occurs with house pseudonyms (e.g. {{A|Maxwell Grant}}).  --Ron ~ [[User:Rtrace|Rtrace]]<sup>[[User talk:Rtrace|Talk]]</sup> 08:40, 1 December 2018 (EST)
 +
::::::I'm going to go ahead and change the early editions that only mention "Lemuel Gulliver" to be by that alternate name.  If anyone disagrees, we can move them to something else.  I would like to ask for opinions on {{t|2088244}} I'm inclined to change that one as well.  It appears to be one of a four volume set of Swift's works.      However, Swift appears on the title page of the [https://hdl.handle.net/2027/uc1.31175035538993?urlappend=%3Bseq=7 first volume] as "J. S, D.D, D.S.P.D.".  For the Gulliver volume, again "Lemuel Gulliver" is the only author listed.  I'm inclined to change this one as well.  Again, if folks object, we can change it to something else.  --Ron ~ [[User:Rtrace|Rtrace]]<sup>[[User talk:Rtrace|Talk]]</sup> 20:15, 13 December 2018 (EST)
 +
 +
== Linking to the Library of Congress -- Help ==
 +
 +
As Annie pointed out the other day, [[Help:How to create a link to a US Library of Congress (Loc) record]] is out of date. We now use External IDs and a Note template to link to Library of Congress records by LCCN. Is there anything on that page that we can salvage? If not, I will zap it next week. [[User:Ahasuerus|Ahasuerus]] 17:14, 1 December 2018 (EST)
 +
:Wouldn't have created it these days, but since we already have it, I updated it to match current practice. There are a couple of cases that it doesn't hurt to explain for new users. I believe I captured current practice correctly, but people should review. I was going to include more specifics on the ebook example (like the actual LoC catalog field name), but the LoC catalog is down now. I will go back and do that at some point. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 09:54, 2 December 2018 (EST)
 +
 +
== Publication tags in advanced search ==
 +
 +
See [http://www.isfdb.org/wiki/index.php/User_talk:Ahasuerus#tag_edit.3F this discussion] for a fuller explanation of the matter. The short version is that advanced search allows you to search for "Tag" in publications and "Title Tag" in titles; however, as Ahasuerus explains, publication tags are not publicly visible anymore after software revisions. Proposal: remove "Tag" from the publication advanced search and rename "Title Tag" to "Tag" in the tile advanced search (which would match the sidebar search, where "Tags" searches titles). Question: does anyone here actually search for publication tags, or have other objections to the proposal? --[[User:Vasha77|Vasha (cazadora de tildes)]] 20:02, 2 December 2018 (EST)
 +
 +
: {{FR|1231}} has been created. [[User:Ahasuerus|Ahasuerus]] 16:13, 9 December 2018 (EST)
 +
 +
:: Done. [[User:Ahasuerus|Ahasuerus]] 18:50, 9 December 2018 (EST)
 +
 +
::: OK, great. --[[User:Vasha77|Vasha (cazadora de tildes)]] 20:31, 9 December 2018 (EST)
 +
 +
== External IDs Data Entry ==
 +
 +
A frequent data entry error that I find myself making is when adding an External ID (usually OCLC/Worldcat or LCCN), I forget to change the type which effectively enters the ID as an ASIN.  I correct these when I notice them and have hopefully caught them all.  I was thinking that it may improve data quality to have a blank ID type as the default (as we do with the length pull down).  Additionally, a client side edit could ensure that a value was selected before sending the edit to the server (like we ensure an author is entered).  The only downside I can think of is that if someone enters a large number of ASINs, it's an extra step.  Clearly, this wouldn't be urgent or a high priority.  Do others feel such changes would be helpful?  --Ron ~ [[User:Rtrace|Rtrace]]<sup>[[User talk:Rtrace|Talk]]</sup> 18:17, 5 December 2018 (EST)
 +
: I’d support making the default an empty string thus forcing a selection. I tend to patrol the ASIN list for anything that does not start with B monthly. There are legitimate cases but most of those need moving elsewhere.  [[User:Anniemod|Annie]] 18:23, 5 December 2018 (EST)
 +
:: There was previously a proposal to add the option to add a Preferences setting for which external ID is at the top by default. I like that better than the blank idea but the blank is better than what we have now. --[[User:Vasha77|Vasha (cazadora de tildes)]] 18:29, 5 December 2018 (EST)
 +
::: Another default will just move the issue - at least with a default in ASIN, we easily find the ones that are forgotten. You move that default to one of the number only IDs (OCLC, GR and so on), it gets exponentially harder. So the more we can do to minimize mistakes, the better... I know that there is the case with people using only one ID type but still... [[User:Anniemod|Annie]] 13:42, 6 December 2018 (EST)
 +
 +
:::: From a purely technical perspective it would be easy to do what Ron proposes. [[User:Ahasuerus|Ahasuerus]] 15:03, 6 December 2018 (EST)
 +
::::: Why not make a combination of both proposals? Allow default setting per user, including blank. [[User:MagicUnk|MagicUnk]] 15:31, 6 December 2018 (EST)
 +
 +
:::::: Different levels of effort I would think -- the adding of the blank is easy enough (add a new element, make sure it is not accepted during submissions on add/edit/clone pub); adding a new default will mean adding new element on the defaults page, changing the three pub pages to account for it and still have the other changes for the empty value. And then there are the priorities - do we really want that more than some other FRs that had been standing and waiting for years? [[User:Anniemod|Annie]] 13:47, 7 December 2018 (EST)
 +
 +
::::::: Right, we have two separate things here. The default blank can be implemented if no one objects (I don't); the option to override it if you're entering lots of IDs of the same type is a low priority idea to keep in mind. --15:40, 7 December 2018 (EST)
 +
 +
:::::::: We already have an FR ({{FR|1163}}) to "Create a new User Preference for the default External ID type", so I have created a new one, {{FR|1230}}, for this issue. [[User:Ahasuerus|Ahasuerus]] 13:24, 9 December 2018 (EST)
 +
 +
=== External IDs Data Entry - First Change Made ===
 +
 +
{{FR|1230}} has been implemented. Depending on your browser, you may need to do a full page reload (Control-F5 under most browsers) for the new functionality to take effect.
 +
 +
Once we determine that everything is working as intended, we can discuss whether:
 +
 +
* we still want to implement {{FR|1163}} (which shouldn't be as labor-intensive as I originally thought), or
 +
* whether the possible unintended side effects as described by Annie above would outweigh its benefits.
 +
 +
[[User:Ahasuerus|Ahasuerus]] 17:36, 9 December 2018 (EST)
 +
 +
: I was just coming to say that this was quick - thanks for the change. EditPub is working as expected. :) [[User:Anniemod|Annie]] 17:39, 9 December 2018 (EST)
 +
::Wanted to say the same thing, but Annie beat me to it.  Thanks. --Ron ~ [[User:Rtrace|Rtrace]]<sup>[[User talk:Rtrace|Talk]]</sup> 17:51, 9 December 2018 (EST)
 +
 +
::: Sure thing. Actually, the change took a few days to code and test. In part it was due to the fact that I used this FR as a test case to get the kinks out of the development process on the new server. I also had to rewrite the way external IDs are validated on the server side because the original design was suboptimal. (Fixer tells me that it was "beyond suboptimal", but I think he is just being cranky because I haven't been able to spend much time with him lately.) [[User:Ahasuerus|Ahasuerus]] 17:56, 9 December 2018 (EST)
 +
 +
:::: I just happened to be in the middle of yet another batch of OCLC identifiers that needed moving and the default changed on me. Thus finding out about it so quickly. And Fixer should stop being cranky - he just had a vacation while his house was getting repainted. Maybe he was just lonely...
 +
 +
:::: Any chance we can add a JS based validation on the front end (in addition to the one we have on the backend) - if it goes down to the yellow warning and you have multiple IDs, all but the first are lost when you go back to reedit (at least in Chrome). Which may get annoying.  :) [[User:Anniemod|Annie]] 18:24, 9 December 2018 (EST)
 +
 +
::::: The browser is supposed to display a pop-up message when an External ID value is entered for a blank External ID type. Did you get that yellow error message before you had a chance to do a full reload (Control-F5)?
 +
 +
::::: P.S. The main reason why I use Firefox for ISFDB editing is that it does a much better job of preserving entered data when I need to go back a page or two. [[User:Ahasuerus|Ahasuerus]] 18:58, 9 December 2018 (EST)
 +
 +
:::::: Yeah, too many open windows - apparently I never reloaded the one - thought I did. Sorry about that. Tried again - works as expected.
 +
:::::: PS: I use FF on my Windows laptop and vastly prefer it to Chrome; the Chromebook has Chrome as a native browser though and it performs a lot better than FF (that essentially runs as an app on the Chromebook). But even FF loses the multiple identifiers (at last the last time I had to back out from a multiple identifier edit). [[User:Anniemod|Annie]] 19:05, 9 December 2018 (EST)
 +
 +
(unindent) I'm in favour of having {{FR|1163}} implemented. I believe it would not sit in the way of anyone that doesn't want a default. And those editors that want a personalized default are assumed to know what they are doing :) [[User:MagicUnk|MagicUnk]] 16:42, 11 December 2018 (EST)
 +
 +
== A "Redo" Button ==
 +
 +
Just wondering - has anyone ever requested a "Give me a redo" button on the edit confirmation page - something that would cancel the just-submitted edit and give you an edit screen with everything you just submitted? ../[[User:Holmesd|Doug H]] 08:18, 10 December 2018 (EST)
 +
 +
: Yes, indeed -- see {{FR|21}}, "Ability to 'Edit' Proposed submission", requested back in 2009. Nothing has been done so far because it would be labor-intensive to implement. [[User:Ahasuerus|Ahasuerus]] 10:41, 10 December 2018 (EST)
 +
 +
:: You may already know this, but as a workaround (and using Chrome in my case), I just press the browser back button, do the necessary changes, (re-)submit, and then cancel the previous edit. Do be aware of one catch; multiple author, external ID,... records are not remembered beyond the first, so you'll have to re-add these. Works like a charm otherwise... [[User:MagicUnk|MagicUnk]] 14:52, 10 December 2018 (EST)
 +
 +
::: Another issue with the "back" option, at least in some browsers, is that you may not retain any additional content items you added past the first nine, and if you're editing an existing publication, you may not retain new content items you added to the ones already there. In short, any part of the form that was added with an "Add Author/Title/External ID/etc." button will not be retained. --[[User:Vasha77|Vasha (cazadora de tildes)]] 15:07, 10 December 2018 (EST)
 +
 +
:::: Or multiple transliterations if I remember correctly (basically the plus signs get a bit wonky using the back button. I tend to compare how much repair work is needed compared to how much time it will take to recreate from the wrong record. [[User:Anniemod|Annie]] 15:13, 10 December 2018 (EST)
 +
 +
(unindent) Yup, run into most of those, which is why I asked. So here's a slightly different take - could the ''Submit'' button be allowed to open in a new window/tab? ../[[User:Holmesd|Doug H]] 16:38, 10 December 2018 (EST)
 +
 +
: That would get messy. It'd be even easier than it is now to submit multiple times (either identical or varying submissions) if you had several tabs open including an open form that you couldn't tell if you'd submitted yet or not. --[[User:Vasha77|Vasha (cazadora de tildes)]] 16:48, 10 December 2018 (EST)
 +
 +
(unindent) Here's a suggestion: How about putting a "cancel this submission" link on the page reviewing the submission. That way, if the editor needs to hit the back button and fix something, or if Doug's suggestion to open the review page in a separate tab is accepted, the editor can easily cancel the erroneous submission before doing the edit, which will make double submissions much less likely. --[[User:Vasha77|Vasha (cazadora de tildes)]] 20:49, 12 December 2018 (EST)
 +
 +
== External Identifiers help updates ==
 +
 +
We really need to update [http://www.isfdb.org/wiki/index.php?title=Template:PublicationFields:ExternalIDs this one] - we had added a lot more of these so the list is a bit obsolete. As it is a live help page, I am reluctant to edit on my own - although if there are no objections, I can do some editing tonight. [[User:Anniemod|Annie]] 13:32, 10 December 2018 (EST)
 +
 +
: Go for it! :) [[User:Ahasuerus|Ahasuerus]] 18:26, 10 December 2018 (EST)
 +
 +
:: Updated. Any updates/recommendations and so on are welcome. I added some notes where finding the ID can be tricky (or confusing) - hopefully that will reduce the number of weird IDs showing all over the place). [[User:Anniemod|Annie]] 20:18, 10 December 2018 (EST)
 +
 +
== Interzone: Digest to Pulp ==
 +
 +
I noticed that the size of recent Interzone issues is 17 cm x 24 cm, which is pulp rather than digest. They should all be changed from 2012 onward. But before I submit these changes I want to make sure I'm not missing anything... [[User:MagicUnk|MagicUnk]] 06:31, 11 December 2018 (EST)
 +
 +
:'Pulp' certainly would be misleading (because of the connotations of a certain period of time and paper quality), though they are not digests either. The issues I have are tps and as this is nowadays an accomplished format for magazines, I'll begin to switch them to that. Would you like to do the same to your verified ones? [[User:Stonecreek|Stonecreek]] 10:42, 11 December 2018 (EST)
 +
 +
::Should we really change them to tp? Size of tps are ill-defined and is a bit of a catch-all if you ask me, whereas pulp is exactly the dimensions we're talking about. I understand pulp is associated with the cheap-paper periodicals, but should'nt we rather expand/clarify the definion instead? Or alternatively, add a new format - equivalent to pulp but with a different name? [[User:MagicUnk|MagicUnk]] 12:34, 11 December 2018 (EST)
 +
 +
:::Well, tps are really well-defined and it seems the standard format for modern (post 2000) print periodicals that don't fit into other magazine standards, and are very similar or identical in format to ''Interzone''. See the following examples: [http://www.isfdb.org/cgi-bin/title.cgi?2313930 Clarkesworld], [http://www.isfdb.org/cgi-bin/title.cgi?2334736 Apex], or [http://www.isfdb.org/cgi-bin/title.cgi?2358173 On Spec]. [[User:Stonecreek|Stonecreek]] 13:19, 11 December 2018 (EST)
 +
 +
::::: Christian, can you elaborate on why you state that tp's are well-defined? When I'm reading the Format field info, it states that its size can be whatever, as long as minimum dimensions are 19 cm tall or 11 cm wide. Not very precise if you ask me... [[User:MagicUnk|MagicUnk]] 16:36, 11 December 2018 (EST)
 +
 +
:::: [[Template:PublicationFields:Format]] says:
 +
 +
::::* Print magazines
 +
::::** '''pulp''' - the common pulp size: 6.5" × 9.5" (16.5 cm x 24.1 cm). For ISFDB purposes this may also be used as a designation for the quality of the paper. There are some untrimmed pulps that are as large as 8" × 11.75 (20.3 cm x 29.8 cm)"
 +
::::** '''tp''' - trade paperback magazines, usually perfect-bound, i.e. periodical publications (often POD) which otherwise would qualify as trade paperbacks (see "tp" in the ''Print books'' section)
 +
 +
:::: The parts that mention paper quality are a big vague: "this '''may''' also be used as a designation for the quality of the paper" and "'''usually''' perfect-bound", but the language seems to suggest that "tp" would be the preferred way of entering modern magazines. I can't think of a better term that we could use, but if there are suitable candidates, we could start a new Rules and Standard discussion. It would be easy to add a new value to the list of supported formats. [[User:Ahasuerus|Ahasuerus]] 14:36, 11 December 2018 (EST)
 +
 +
::::: '''mm''' for '''m'''odern '''m'''ags, or '''modern''' for short? [[User:MagicUnk|MagicUnk]] 16:39, 11 December 2018 (EST)
 +
 +
:::::: OK, changed. [[User:Stonecreek|Stonecreek]] 06:11, 13 December 2018 (EST)
 +
 +
== Nonstandard capitalization in a poem title ==
 +
 +
I'm having a slight disagreement with Christian. The title of [http://www.isfdb.org/cgi-bin/title.cgi?2479735 this poem] is printed "YUAN: the Origin of a Family Name" in the issue of ''Mithila Review'' that I catalogued. Christian thinks the capitalization should be standardized to "Yuan: The Origin of a Family Name" in the database. But I  disagree because of the part of the ISFDB policy that states "Titles should have case regularized according to language-specific rules unless there is some specific evidence that the author intended certain letters to be in a specific case." I think it is clear that the author intends YUAN to be all caps because it appears that way not just in ''Mithila Review'', but in its [https://www.amazon.com/dp/B07J3955D7/ other publication] in ''Manifest West: Transitions and Transformations''.
 +
 +
On the other hand, ''Mithila Review'' prints the word "the" after the colon lowercase, but ''Manifest West'' prints it uppercase. I have no problem with standardizing that word to the usual uppercase. So, the result should be "YUAN: The Origin of a Family Name." What do you think? --[[User:Vasha77|Vasha (cazadora de tildes)]] 14:11, 11 December 2018 (EST)
 +
 +
:: Looking at Piers Anthony, you get "DoOon Mode" and "OX", which make sense in the context of the story, but you also get "SOS the Rope" followed by "Var the Stick" and "Neq the Sword" and the inconsistency looks weird. Is the capitalization consistent through the story/article? ../[[User:Holmesd|Doug H]] 22:27, 11 December 2018 (EST)
 +
 +
::: Read the poem [http://mithilareview.com/yuan_06_18/ here]: it goes through the name letter by letter which makes Y-U-A-N a sort of acronym! --[[User:Vasha77|Vasha (cazadora de tildes)]] 23:19, 11 December 2018 (EST)
 +
 +
:::: Hi, Vasha! If you'd stated something like that in the notes it would have been obvious why the capitalization was chosen. I'll change the title and add a note. [[User:Stonecreek|Stonecreek]] 23:47, 11 December 2018 (EST)
 +
 +
::::: OK, thanks. The thing is, though, a lot of poems use weird capitalization without such an obvious reason for it. You kind of just have to accept that what's in the publication is what is intended. I tend to standardize the capitalization of story titles but not poem titles.
 +
 +
::::: Does anyone want to start a R&S debate over what constitutes "some specific evidence that the author intended certain letters to be in a specific case"? --[[User:Vasha77|Vasha (cazadora de tildes)]] 00:08, 12 December 2018 (EST)
 +
 +
:::::: Most moderators should be accustomed with all-small-letters for poems, but for cases like this one (or others that may deviate in other ways) it really seems better to add an explanatory note to the title: the next editor / moderator might think in the same way as me and change the title back again. [[User:Stonecreek|Stonecreek]] 04:38, 12 December 2018 (EST)
 +
 +
::::::: Notes are always good :-) [[User:Ahasuerus|Ahasuerus]] 13:18, 12 December 2018 (EST)
 +
 +
== New cleanup reports - External IDs ==
 +
 +
Seven new cleanup reports have been deployed as per {{FR|1232}}, which see for details. The data -- a couple hundred publications -- will become available tomorrow morning. Based on preliminary testing results, one of the reports may need the ability to "ignore" records added, but let's wait until everything else has been corrected.
 +
 +
I was going to start working on other recently requested FRs, but it looks like I need to take a break since I am not feeling well. Hopefully a short one. (Fixer says that he has a custom anti-virus program ready for me, so I am sure I'll be fine. If you can't trust Fixer, who can you trust, right?) [[User:Ahasuerus|Ahasuerus]] 23:21, 11 December 2018 (EST)
 +
 +
: Some fun new reports turned out these to be. Some people might need to see an optometrician, if you'd ask me.--[[User:Dirk P Broer|Dirk P Broer]] 11:38, 12 December 2018 (EST)
 +
 +
:: Well, we have a tad over 532,000 pubs and 220,000 external identifiers on file, so 200 problem pubs is around 0.1%. Even Fixer agrees that it's not too bad for carbon-based lifeforms :-) [[User:Ahasuerus|Ahasuerus]] 13:34, 12 December 2018 (EST)
 +
 +
::: 0.1% is indeed very acceptable. Some of the titles are in the report by error too, e.g. [http://www.isfdb.org/cgi-bin/pl.cgi?493352 Der Zeitagent].--[[User:Dirk P Broer|Dirk P Broer]] 17:04, 12 December 2018 (EST)
 +
 +
:::: Der Zeitagent's OCLC ID was displayed as "74965890", but the actual stored value was "74965890</". The angle bracket and the slash were not displayed because browsers interpreted them as HTML markup.
 +
 +
:::: The [http://www.isfdb.org/cgi-bin/edit/cleanup_report.cgi?244 4 tagged Japanese pubs] may require more digging -- I will ping Nihonjoe. [[User:Ahasuerus|Ahasuerus]] 17:24, 12 December 2018 (EST)
 +
:::::Fixed! Well, mostly. See my talk page. ···[[User:Nihonjoe|<font color="darkgreen">日本穣</font>]] · <small>[[Special:Contributions/Nihonjoe|<font color="blue">投稿</font>]] · [[User talk:Nihonjoe|Talk to Nihonjoe]]</small> 20:20, 12 December 2018 (EST)
 +
 +
:::::: Thanks! The NDL-specific logic has been adjusted to allow leading "b"s. [[User:Ahasuerus|Ahasuerus]] 23:33, 12 December 2018 (EST)
 +
 +
::::::: The LCCNs also seems to be able to have a few letters as a lead (a, ac, unk, tmp, ltf and war are the ones I saw today but there aren't too many of them so let's leave the LCCN report as is - we can just ignore them for now when they show up. I will keep an eye for some of them getting too plentiful. [[User:Anniemod|Annie]] 00:12, 13 December 2018 (EST)
 +
 +
== ISFDB Statistics page ==
 +
 +
The [http://www.isfdb.org/cgi-bin/stats.cgi?4 ISFDB Statistics] page has been updated to display External ID information. The data will become available tomorrow morning. [[User:Ahasuerus|Ahasuerus]] 20:18, 12 December 2018 (EST)
 +
 +
== Google Search - Take One ==
 +
 +
As per {{FR|1226}}, Advanced Search has been enhanced. The new section, cleverly called "Search ISFDB Using Google", lets you select one of the currently supported record types:
 +
 +
* name (default)
 +
* title
 +
* series
 +
* publication
 +
* publication series
 +
* publisher
 +
* award category
 +
 +
and then choose between "contains approximate word" (the default) and "contains exact word". I have tweaked the Google query syntax to approximate what I think users will expect to get. However, Google's search algorithms are somewhat mysterious, so the results are occasionally a bit odd, especially if you move to pages 2, 3, etc. Still, a search on "ПАВЕЛ ВЕЖИНОВ" (Annie's example from the original discussion) finds "Павел Вежинов" and, if you choose "approximate", also finds "Pavel Vejinov", which is more than we can currently do.
 +
 +
Please let me know what you think of the current implementation. If we have developers familiar with the way Google Search works, I'd appreciate their feedback.
 +
 +
If and when we determine that this is useful, we can update the regular search logic to display a "Google Search" button if a search fails to find anything. [[User:Ahasuerus|Ahasuerus]] 23:36, 13 December 2018 (EST)
 +
 +
: I am not sure if it is just my security settings or a generic problem with Chrome but the forward to Google does not work (Ctrl + F5 did not clear it either). A right click to open in a new tab works - but not a straight click. Will check with FF and another Chrome tomorrow morning. Other from that - nice! [[User:Anniemod|Annie]] 00:25, 14 December 2018 (EST)
 +
 +
:: Curious. Here is what Chrome says:
 +
 +
::* Refused to send form data to 'https://www.google.com/' because it violates the following Content Security Policy directive: "form-action 'self' http://www.isfdb.org".
 +
 +
:: We do have this CSP directive in place as part of our security framework. However, I don't think it should apply in this case because the code uses a server-side redirect rather than a direct submission. Firefox apparently agrees and processes the redirect seamlessly. I'll do more digging tomorrow morning -- thanks for the heads-up! [[User:Ahasuerus|Ahasuerus]] 00:42, 14 December 2018 (EST)
 +
 +
::: It turns out that this is a [https://github.com/w3c/webappsec-csp/issues/8 known issue]. Firefox interprets one of the Web security standards one way while Chrome and Safari interpret it another way. I am currently in the process of trying to come up with a workaround that will work for all browsers. [[User:Ahasuerus|Ahasuerus]] 12:33, 14 December 2018 (EST)
 +
 +
:::: And now I remember why I hate doing web development. Thanks for looking into this :) [[User:Anniemod|Annie]] 12:42, 14 December 2018 (EST)
 +
 +
::::: The internet (and computers in general) have been growing so fast over the last few decades that half the time I am surprised that things work at all. On occasion I feel like Buster Keaton in [https://en.wikipedia.org/wiki/The_Electric_House ''The Electric House'']... [[User:Ahasuerus|Ahasuerus]] 13:26, 14 December 2018 (EST)
 +
 +
:::::: The software has been adjusted to work with Chrome and Safari. [[User:Ahasuerus|Ahasuerus]] 14:25, 14 December 2018 (EST)
 +
 +
::::::: Thanks! Appears to be working (on Chrome on Windows; will check the Chrome on the Chromebook tonight).
 +
 +
::::::: PS: Yeah and things change faster and faster these days. It is almost frightening when you are the one building what people need to use... [[User:Anniemod|Annie]] 14:50, 14 December 2018 (EST)
 +
 +
(Unindent) It works on Microsft Edge and the Samsung browser too. --[[User:Vasha77|Vasha (cazadora de tildes)]] 17:54, 14 December 2018 (EST)
 +
 +
: Thanks for checking! [[User:Ahasuerus|Ahasuerus]] 20:10, 14 December 2018 (EST)
 +
 +
== Cleanup reports - consolidation ==
 +
 +
We have 245 nightly cleanup reports. It's a good thing, of course, but the software was not originally designed to have that many reports and things have become unwieldy.
 +
 +
I am currently in the process of consolidating and streamlining the code. The first patch was installed a few minutes ago and will affect the nightly run in 2 hours. I expect more patches to follow in the next day or two. There should be no user-experienced changes, but if you notice anything strange, please report your findings here. [[User:Ahasuerus|Ahasuerus]] 23:04, 14 December 2018 (EST)
 +
: If you accept ideas for consolidation, all those language specific transliteration reports can be merged together. Same with suspected author languages and so on. They were huge when we started the transliterations and the title languages but these days they are either empty or very small... [[User:Anniemod|Annie]] 01:47, 15 December 2018 (EST)
 +
 +
:: The number of records that we were originally dealing with was one of the reasons why multiple language-specific "transliteration" reports were created. However, there was another reason: most of us are not able to add transliterated values across the language spectrum. I can do it for European languages, but Japanese is beyond me. On the other hand, Nihonjoe can handle Japanese, but not Bulgarian, Serbian, Russian, etc. Thus even though the number of records found by these nightly reports is low these days, segregating them by language still seems useful. If I look at the list and see that only Asian languages are outstanding, I don't need to drill down since I can't help anyway. [[User:Ahasuerus|Ahasuerus]] 13:44, 15 December 2018 (EST)
 +
 +
::: Except that the catch-all is not just Asian languages - Croatian ends up there for example. Or Bosnian. Or any number of other languages we do not see often. So I end up always checking it anyway - and seeing that it is an alphabet I do not know, I just skip these. :) But if you think they are useful as they are, no worries. I was just thinking aloud. [[User:Anniemod|Annie]]
 +
 +
:::: Would it help to consolidate all of our "transliterated" reports based on whether the language's primary alphabet/script is:
 +
 +
::::* Latin-based
 +
::::* Cyrillic-based
 +
::::* Other
 +
 +
:::: ? It wouldn't be perfect because of multi-alphabet languages like Azerbaijani, Serbian, etc, but it may be an improvement. [[User:Ahasuerus|Ahasuerus]] 15:25, 15 December 2018 (EST)
 +
 +
::::: The way I work on these reports - yes. Make a decision for the multi-alphabet ones (stick them with the less-common one would be my vote- if you read Cyrillic for example, you can deal with the Latin forms of the same alphabet) and we are all set. [[User:Anniemod|Annie]] 15:34, 15 December 2018 (EST)
 +
 +
== Some absent Theodore Sturgeon reviews ==
 +
 +
I've had a snail-mail enquiry from American fan John Hertz (he's never had email, ever, and never will) who has noticed that we include book reviews that Theodore Sturgeon did for ''Galaxy'' 1972-1975, ''Venture'' 1957-1958, but not ''National Review'', ''The New York Times'' or, to be complete, ''Hustler'' (under Paul Krassner, ed. 1979-1983).
 +
 +
Unless I've missed it somewhere, I see nothing under the Rules of Acquisition the specifically prevents us from including reviews by a prominent genre author such as Sturgeon that appeared in non-genre periodicals – can anyone point to examples of periodicals where we do include such reviews? And if not, is there a reason for this exclusion or is it just lack of the necessary bibliographic data? A cursory look at [http://etext.ku.edu/view?docId=ksrlead/ksrl.sc.sturgeontheodore.xml The Kenneth Spencer Research Library] shows such reviews are listed there, and maybe John Hertz knows of other resources. John's enquiry about our missing bibliographic detail shows this is obviously important to some people who would expect to find such information at our site. Input please! Thanks. [[User:PeteYoung|PeteYoung]] 07:59, 15 December 2018 (EST)
 +
:[[Help:Entering non-genre periodicals#Genre special issues]] has "even though we do not normally catalog non-fiction from non-genre magazines" which isn't definitive. It's been discussed a couple of times with no real conclusion. You will occasionally see non-fiction included when there is fiction, but non-fiction from a non-genre magazine without accompanying fiction is pretty much not done (though it wouldn't surprise me if some has made its way into the database). --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 08:55, 15 December 2018 (EST)
 +
 +
::I'd vote for an inclusion of reviews that take on genre titles and such done by authors above-the threshold, regardless of where they were published: both cases are useful for completing our core business (genre authors, their works and how they are viewed). [[User:Stonecreek|Stonecreek]] 07:41, 16 December 2018 (EST)
 +
 +
:::The rules of acquisition declare "works about speculative fiction" as "in" ([[ISFDB:Policy#Included|Included #3]]).  So I believe a review of a title eligible for inclusion is likewise eligible for inclusion, regardless of where it was published.  But the rules of acquisition also limit inclusion of non-genre non-fiction by authors above the threshhold to that published "as a standalone book" ([[ISFDB:Policy#Included|Included #4]]).  So I believe a Sturgeon review of a non-genre title in a non-genre periodical is explicitly excluded.  I don't have a strong feeling about it, but that treatment seems appropriate to me.  --[[User:MartyD|MartyD]] 10:02, 16 December 2018 (EST)
 +
 +
:::: I've gotten the impression that that "works about speculative fiction" inclusion is also pretty much limited to stand-alone works. Not that there's a set-in-stone policy about it, just that several discussions over the past three years have shown the current group of editors to be unenthusiastic about cataloguing nonfiction and unwilling to interpret rules in ways that would allow much of it to be entered. Somebody (I unfortunately don't recall who) said that they thought nonfiction should only be entered in order to show what the complete contents of genre magazines are. That's an extreme position, but no one really disagreed with it in that discussion. For my part, though, I don't think it would do any harm to enter some non-genre periodicals if they have interesting contents. An exception here or there, in order to have the complete genre writings of significant authors included, not just their complete genre ''fiction''. --[[User:Vasha77|Vasha (cazadora de tildes)]] 10:35, 16 December 2018 (EST)
 +
 +
(unindent) One of the problems that we have run into when discussing what types of non-fiction to include is the sheer number of different ways to categorize them. Off the top of my head:
 +
 +
* Length: books vs. short works. Short works are further subdivided into:
 +
** Essays vs. reviews vs. interviews
 +
* Type of publication where the non-fiction work appeared: genre periodicals vs. non-genre periodicals vs. genre books vs. non-genre books
 +
* Type of non-fiction work: works about written SF vs. works about non-written SF (comics, films, TV, etc) vs. works about non-genre issues vs. works that are "sort of" related to SF (space exploration, history of myths, etc)
 +
 +
This segmentation makes it difficult to ensure that everyone is on the same page when discussing proposals that cover only certain "cells" of this multidimensional matrix. Perhaps a graphical (tabular?) representation may help clarify what our policy currently says and where we may want to go from here. [[User:Ahasuerus|Ahasuerus]] 16:44, 16 December 2018 (EST)
 +
 +
== In memoriam -- magazines ==
 +
 +
It's been a bad, bad year in genre magazine publishing. Numerous long-lived, respected, and beloved magazines announced their closure: ''Space & Time'' after 52 years of operation, saying that the economics of the distribution system have changed so that it is impossible for them to stay in print; ''Mythic Delirium'' after 20 years, ''Shimmer'' after 14 years, ''SQ Mag'' after 8 years... Young adult spec fic lost a pro-paying market with the end of ''Cicada'' magazine. Other magazines struggle to stay in production: ''Cemetery Dance'' did not produce an issue this year, and ''Lackington's'' only delivered two issues instead of its customary four. The ''Strange Horizons'' fundraiser was not quite as successful as they'd hoped. Economic woes were everywhere. Although new magazines were launched, hope was greater than reality: the revived ''Omni'', greeted with enthusiasm, lasted one issue. I very much enjoyed the first two issues of ''Eyedolon'' magazine, but since then their production of new content has been sparse.
 +
 +
Genre short fiction will still be published--it must be, since people will not stop writing and reading it. But the chances of writers being paid for their work continue to grow worse and worse. Magazine publishing as we know it is changing, and magazines are fewer. I don't know what form short fiction publishing will take in the future. I send respectful thanks to the magazines that have ended their run this year, and hopeful wishes to everyone who intends to keep publishing. --[[User:Vasha77|Vasha (cazadora de tildes)]] 15:43, 15 December 2018 (EST)
 +
 +
: Unfortunately, I know very little about the short fiction market these days, so I can't venture any guesses as to what's going on. It would be great if we could mine our data for patterns, but all I can think of at the moment is [http://www.isfdb.org/cgi-bin/stats.cgi?5 "Titles by Year of First Publication"], which has separate graphs for novels and short fiction, and [http://www.isfdb.org/cgi-bin/stats.cgi?6 "Publications by Year"], which has a graph for magazines. They are not terribly illuminating, but they are better than nothing.
 +
 +
: Since I am still recovering and can't do heavy duty development work, I have added a POEM graph to "Titles by Year of First Publication". The data will become available tomorrow morning. Perhaps we should add a graph showing the breakdown of magazine formats (pulp, digest, webzine, etc) to [http://www.isfdb.org/cgi-bin/stats.cgi?10 "Percent of Publications by Format by Year"]? The "Space & Time" editor [http://www.spaceandtimemagazine.com/editors-blog/future-update-space-time/ mentioned] that:
 +
 +
:* As for going online only, there’s already a glut of high-quality genre publications vying for eyeballs — it’s simply not worth the effort required to assemble issues for so small a readership.
 +
 +
: It may be useful to try to quantify this "glut", as she called it. [[User:Ahasuerus|Ahasuerus]] 21:32, 15 December 2018 (EST)
 +
 +
:: I realize that my ill-chosen headline makes it sound like I intended to say "The genre magazine is dead!" I did not mean that, I just meant to post an in memoriam and thanks to certain specific magazines that ended their run this last year. That led to reflecting that the general situation is in transition to who-knows-what. --[[User:Vasha77|Vasha (cazadora de tildes)]] 04:12, 16 December 2018 (EST)
 +
 +
::: In my experience, when a well-read genre fan thinks that the field has changed, there is a very good chance that he or she is right. However, determining the ''nature'' of the change may not be easy. Granted, in certain cases, e.g. during the "death of [US] science fiction" period in the late 1950s and early 1960s, it was fairly straightforward. All you had to do in 1962 was plot the annual number of SF magazines and magazine issues since 1953 and the picture was perfectly clear. Hence {{A|Alva Rogers}}' {{T|102937|A Requiem for Astounding}} in 1964, although he also argued that, in addition to a quantitative decline, science fiction had lost its "sense of wonder", a much more difficult proposition to prove or disprove.
 +
 +
::: However, in most cases things are not that simple. Sometimes the relative popularity of sub-genres changes. For example, the recent flood of urban fantasy and paranormal romance works has done little for cyberpunk fans. Other times the underlying change is technological in nature: readers who are less willing to use e-books may have been negatively affected by the changes over the last 10+ years. Then there are generational and esthetic changes as was the case during the "New Wave" controversy of the late 1960s. And so on and so forth.
 +
 +
::: It would be great if we could use our data to quantify these changes. For example, in addition to the ideas that I mentioned earlier, perhaps we could update [http://www.isfdb.org/cgi-bin/stats.cgi?7 Titles by Author Age] to show how the "age at the time of first publication" has changed over the years. Or we could show how the average magazine editor age has changed over time. We could also create a graph showing changes in the relative popularity of various title tags. More ideas are always welcome! [[User:Ahasuerus|Ahasuerus]] 15:29, 16 December 2018 (EST)
 +
 +
== REVIEW, INTERVIEW, COVERART and INTERIORART series ==
 +
 +
As per {{FR|1213}}, "Let all title types appear as series", the software has been modified to fully support REVIEW series. INTERVIEW, COVERART and INTERIORART series are still outstanding. [[User:Ahasuerus|Ahasuerus]] 19:22, 16 December 2018 (EST)
 +
 +
: Support for INTERVIEWs has been added. You can now put them in a series and they will appear correctly -- see {{A|William Sullivan}}'s Summary page for an example. [[User:Ahasuerus|Ahasuerus]] 19:59, 16 December 2018 (EST)
 +
 +
:: Support for COVERART and INTERIORART series has been added.
 +
 +
:: In most cases everything looks OK, e.g. see {{A|Alfons Figueras}}'s Summary page. However, mixing COVERART and INTERIORART titles in the same series can lead to unexpected results. For example, if you pull up {{A|Virgil Finlay}}'s Summary page and scroll down to the "Cover Art Series" section, you will note that the "Virgil Finlay's Poetry Series" series contains 22 INTERIORART titles and only 1 COVERART title. This is due to the fact that the Cover Art section is displayed before the Interior Art section: all INTERIORART titles that belong to a series with at least one COVERART title in it are displayed in the "Cover Art Series" section. This is the way all other title types work, so I don't think we need to change the software, but we'll want to keep it mind when adding series information to art titles. In certain cases creating two separate series may be a better way to organize our art records. Let's wait a few days and then we can discuss whether we need to create a cleanup report for "mixed art" series.
 +
 +
:: Finally, please note that I have moved the 2 art sections below "short fiction", "poems" and "essays". We are primarily a fiction database, so it makes more sense to display fiction titles before art titles. If this causes a problem, we can revisit the display order. [[User:Ahasuerus|Ahasuerus]] 21:04, 16 December 2018 (EST)
 +
 +
=== Interviews BY vs. Interviews WITH ===
 +
 +
I can't decide whether it makes sense to have them displayed in series on the interviewer page but not the interviewee page. It is definitely nice to have the interviewer displayed this way. Now it makes sense that we've been adding the Lightspeed and Nightmare author spotlights to series, because it looks good to have the recurrent work the interviewer did for this department displayed together on their page. In the case of author spotlights, some interviewees have been interviewed multiple times for Nightmare and Lightspeed, and it might look good to have those grouped together too; but in general, it makes rather less sense to have the interviewee displayed in series because often they've just contributed once to that series. --[[User:Vasha77|Vasha (cazadora de tildes)]] 20:53, 16 December 2018 (EST)
 +
 +
: One thing to keep in mind is that the "Interviews WITH" section is very different from the other sections on the Summary page. It displays titles that the main author is ''associated'' with, but is not the author of. For this reason the software that displays "Interviews With" is completely different and not as robust as the rest of the software on that page. For example, it doesn't handle VTs -- see {{FR|1337}}, "Display VTs in the Interviews With This Author section of Summary pages". We can modify it, but it's a fairly big can of worms. [[User:Ahasuerus|Ahasuerus]] 21:12, 16 December 2018 (EST)
 +
 +
:: OK then, it's a good thing I decided I didn't want the "interviews with" displayed in series if it isn't possible anyhow! --[[User:Vasha77|Vasha (cazadora de tildes)]] 21:32, 16 December 2018 (EST)
 +
 +
== The External IDs migration ==
 +
 +
Just in case anyone is interested, as of 5 minutes ago all external identifiers that were in the Notes fields as links had been either moved to the new fields or templated. Additionally all non-linked ones in predictable (and sometimes not so predictable patterns) had been also dealt with. All wrongly templated ones mainly from March-August 2017 (when we were still figuring out what we were doing) that should have been in the new fields were also checked and moved if needed. So if you are tired of your "Changed Primary Notifications" getting lighted up as a Christmas tree daily, that will stop happening. Until we have another cleanup project that requires that many publications edits that is. :)
 +
 +
If anyone finds a non-moved/templated ID, please move/template it if it makes sense (lccn that cannot be found in LOC for example stays unmoved and untemplated and so on). Or post here or on my wall so I can move it. If you find a pattern yielding more than one, I will be more than happy to work through them.
 +
 +
But for now, besides the 23 Japanese Audible ASINs that we are still researching, the moving of external IDs is completed. [[User:Anniemod|Annie]] 02:12, 19 December 2018 (EST)
 +
 +
:Wow, that was a load of work. Great that you did this Herculian task, Annie! [[User:Stonecreek|Stonecreek]] 02:15, 19 December 2018 (EST)
 +
 +
:: Congratulations on slaying the dragon! Don't look now, but there is another weyr right around the corner :-) [[User:Ahasuerus|Ahasuerus]] 08:01, 19 December 2018 (EST)
 +
 +
::: Ahasuerus, just the one? :) Christian, that one was a team effort - at different times in the last 18 months pretty much everyone chipped at these. Although a couple of weeks ago I did wonder briefly if I will ever stop finding more and more creative ways found by the editors to record these IDs in the Notes and if just giving up on patterns and opening every single publication won't be faster (nah, it would not have been - but those things just kept showing up). If anyone ever needs a proof on why we need more structured fields, this migration will probably be the example in the dictionary. :)
 +
 +
::: Onto the next project now. [[User:Anniemod|Annie]] 10:39, 19 December 2018 (EST)
 +
 +
:::: Annie hunts IDs, she finds them where they lurk / Tireless editor, to you we say "Great work!" --[[User:Vasha77|Vasha (cazadora de tildes)]] 11:00, 19 December 2018 (EST)
 +
 +
(unindent) The cleanup report has been simplified to look for any and all occurrences of 'worldcat.org/" in the Note field. The new version of the report lets moderators "ignore" records. I expect that of the 19 records that the report will find when it runs overnight all (or almost all) will be "ignored" tomorrow morning. [[User:Ahasuerus|Ahasuerus]] 17:42, 19 December 2018 (EST)
 +
 +
: Thanks for updating that one. Unless someone manages to smuggle a new one in, [http://www.isfdb.org/cgi-bin/note_search_results.cgi?OPERATOR=contains&NOTE_VALUE=worldcat.org/#Publications all 19] will be ignored as soon as the report manages to regenerate :) [[User:Anniemod|Annie]] 18:05, 19 December 2018 (EST)
 +
 +
== New OCLC cleanup reports ==
 +
 +
Two new cleanup reports have been deployed:
 +
 +
* Publications with an OCLC Verification, no ISBN and no OCLC External ID
 +
* Publications with an OCLC Verification, an ISBN and no OCLC External ID (first 1000)
 +
 +
The only difference between them is that the second one has an extra column for the ISBN. Displayed ISBNs are also linked to OCLC.
 +
 +
There is no way to "ignore" records at this point. We may need to revisit this issue once the bulk of the records has been processed: there are some unusual scenarios involving magazines and OCLC errors.
 +
 +
The data will become available tomorrow morning. I expect that the first cleanup report will have 397 records. The second report should find approximately 3,621 records, but the display is capped at 1,000 for performance reasons. We are getting ever closer... [[User:Ahasuerus|Ahasuerus]] 19:30, 19 December 2018 (EST)
 +
 +
: I will make that case that if it does not have an OCLC record to connect to, it should not have been marked as verified... Verified means "there is a record describing THIS book" and I verified against it, not a book or series related to this book or containing this book (this is what templates are for)... [[User:Anniemod|Annie]] 19:40, 19 December 2018 (EST)
 +
 +
:: If all OCLC-verified publications end up with an OCLC ID, it will effectively make OCLC verifications redundant. At that point we will presumably want to consider whether we want to keep OCLC as an active verification source. Since some editors grow attached to their verifications, we may want to preserve their contributions on the [http://www.isfdb.org/cgi-bin/stats.cgi?2 Top Verifiers] page, which shouldn't be hard to do. I guess we'll revisit this issue once the new cleanup reports have been processed. [[User:Ahasuerus|Ahasuerus]] 16:37, 20 December 2018 (EST)
 +
 +
(unindent) How do we look in the other direction - publications with OCLC number but without a verification? Some of those will be as easy as a click; some will need updated notes to note discrepancies, some may actually end up with us updating our records. [[User:Anniemod|Annie]] 10:22, 21 December 2018 (EST)
 +
 +
: I guess it depends on what we decide to do with OCLC verifications. My tentative take on them is that OCLC IDs effectively supersede OCLC verifications. The additional information that secondary verifications provide -- the "N/A" capability, the name of the editor and the date of the verification -- doesn't seem to add much as long as we have OCLC IDs. If that's what we end up deciding, then we'll probably "freeze" OCLC verifications, i.e. disallow new ones and possibly stop displaying the existing ones. We won't be deleting them from the database in case we ever change our mind. They will also be displayed on our statistical reports. [[User:Ahasuerus|Ahasuerus]] 22:23, 21 December 2018 (EST)
 +
 +
:: That is a good plan. I also think there's likely no need to double-check the OCLC IDs that don't have verifications; although doubtless some of them are wrong, they're no more likely to be wrong than the verified ones. And although it's nice to note discrepancies between the WorldCat record and other sources of data, how high a priority is that?  --[[User:Vasha77|Vasha (cazadora de tildes)]] 22:46, 21 December 2018 (EST)
 +
 +
::: Low priority for you is not the same as low priority for someone else. We are talking about editors' time here - everyone works on what they find relevant to them. So let's not make decisions for other people... And if data quality and proper notes are low priority, especially when we work from secondary sources, maybe we have a different ideas of what is important :) [[User:Anniemod|Annie]] 23:27, 21 December 2018 (EST)
 +
 +
:::: Noted, my apologies. --[[User:Vasha77|Vasha (cazadora de tildes)]] 00:25, 22 December 2018 (EST)
 +
 +
:: I had found the name of the OCLC verifier useful - they are usually the source of a lot (if not all) of the information in the record and additional questions often find answers by asking them when there is no PVs or when they are inactive. So I will be reluctant to lose or stop recording this information... [[User:Anniemod|Annie]] 23:27, 21 December 2018 (EST)
 +
 +
::: Interesting. I recall occasionally using secondary verifications in a similar fashion, but I didn't realize that it was a common practice. Just goes to show how different different editors' workflows can be. I guess we'll revisit this issue once we wrap up these 2 cleanup reports.
 +
 +
::: It also raises a larger issue -- how do we make "publication history" available to editors? A while back we added "My Recently Changed Primary Verifications" to our toolset, but it's more of a notification mechanism. There was an early attempt to create a general-purpose "Edit History" system, but it failed because our submissions do not capture "before" and "after" states. There is an outstanding request to [http://www.isfdb.org/wiki/index.php/ISFDB:Current_events#Rules_and_standards_changes Create a history of changes to primary-verified publications by storing a snapshot of the way each verified pub looked like right before it was changed], but it's also limited to primary-verified pubs.
 +
 +
::: One possible "low-hanging fruit" that comes to mind is linking Publication records to the submissions that originally created and subsequently modified them. We can easily do it for "New Publication" submissions because we added a "New Record ID" field to the submission table a few years ago. Linking to "Edit Publication" submissions is currently impossible because submissions do not store the IDs of the publications that they modify in a structured manner. However, it should be possible to extract them from the body of each submission and create a new field. Food for thought. [[User:Ahasuerus|Ahasuerus]] 13:32, 22 December 2018 (EST)
 +
 +
:::: I had been working on a lot of housekeeping tasks so I probably had edited a lot more publications I am not verifying than most editors had. Which is probably why I've need to discuss something with a secondary verifier (and not just OCLC - the whole board of secondary verifications). Not sure how common it is in a "normal" workflow... :)
 +
 +
:::: For the publication history: That will still have the problem with tracking the editing of titles - a lot of the changes in a publication are not done from the pub page but in an underlying titles - and we still have a blind spot there.  While tracking the pub changes will be useful, it will be incomplete in showing the full story of what actually did happen. And with titles jumping pubs occasionally, it can get progressively harder to track the history (although we do have timestamps so we know when something is moved in or out). But yeah, if we can see who edited, we do not need a name on the verifications... [[User:Anniemod|Annie]] 15:33, 22 December 2018 (EST)
 +
 +
::::: Oh sure, a "publication edit history" limited to New/Add/Clone edits would be incomplete. Still, I suspect that it would be a significant step forward and shouldn't be too hard to implement. It would also be retroactive since we would be linking all 2006-2018 submissions to their publication records. On balance, it may be a cost-effective palliative solution. [[User:Ahasuerus|Ahasuerus]] 16:20, 22 December 2018 (EST)
 +
 +
:::::: :) I agree, it is better than what we have now - and things get built step by step. Can we easily add import and removeTitle (both to the "Changed" list and to this? Those are always tied to the publication as well - it at least gives us one more of the actions. I know that merging and deleting may make these a bit hard to track but still... maybe even the ones that are around will be a good enough help... [[User:Anniemod|Annie]] 17:15, 22 December 2018 (EST)
 +
 +
::::::: Good point. {{FR|1237}}, "Enhance 'My Recently Changed Primary Verifications'", has been created. I have also created {{FR|1238}}, Create an Edit History page for publications. [[User:Ahasuerus|Ahasuerus]] 15:03, 26 December 2018 (EST)
 +
 +
== Capturing Non-Linking Secondary IDs in a Structured Way ==
 +
 +
(Copied from [[ISFDB:Moderator_noticeboard#Capturing_IDs_in_a_Structured_Way]] -- see '''the sub-section at the bottom for my proposal'''.)
 +
 +
=== Original Discussion ===
 +
 +
One other advantage of having these [non-linking secondary] IDs in the database is that their presence makes it possible to check for gaps in our coverage. Since Reginald used sequential numbers (000001 through 37651) for first editions, we could easily create a cleanup report to look for gaps. Of course, it would be even easier to implement and display if we captured these IDs in a more structured way. [[User:Ahasuerus|Ahasuerus]] 16:49, 18 December 2018 (EST)
 +
 +
: So are we back to "Let's have a non-linking External IDs" in their own list? And these will be extremely easy to move programmatically - they are very well (and predictably) structured in their notes - almost always alone on a line - so we can parse and dump the line...  :) [[User:Anniemod|Annie]] 18:31, 18 December 2018 (EST)
 +
 +
:: I can think of two different programmatic solutions:
 +
::* Create a new set of fields that would be similar to the "External IDs" box but without the linking
 +
::* Modify the logic behind External IDs to allow non-linking IDs
 +
::The second solution would be much easier to implement. I suspect that it would also be more intuitive for users and editors. [[User:Ahasuerus|Ahasuerus]] 22:00, 18 December 2018 (EST)
 +
 +
::: I'd vote for the second approach. It also has the built-in capability to switch non-linking to linking with a simple server edit (as opposed to some type of reclassification depending on the design). [[User:Anniemod|Annie]] 22:19, 18 December 2018 (EST)
 +
 +
: In theory (I'm sure this isn't practicable) it'd be nice to have IDs associated with the secondary verification checkboxes. The numbers that people are defending the usefulness of are ones where the book itself was considered useful enough to add to secondary verifications. In the case of Reginald, it would be very nice to have the reference number displayed next to the verification; more complicated in the case of OCLC where there can be multiple numbers. We have many OCLC numbers without Worldcat verification checked and vice versa, and it's somewhat redundant to have both. --[[User:Vasha77|Vasha (cazadora de tildes)]] 18:33, 18 December 2018 (EST)
 +
 +
:: Interesting points, some of them in line with what I have been thinking. I will mull it over and respond tomorrow. [[User:Ahasuerus|Ahasuerus]] 22:44, 18 December 2018 (EST)
 +
 +
::: Most of the external IDs are defacto verifications anyway - just not against the usual American sources and we do not keep record of who added them... For a Russian book I am much more likely to trust and check FantLab than OCLC and most of the information will come from the Russian source. Same for SFBG for Bulgarian, DNB for German and so on. And most editors had treated these as verification sources - by noting differences between sources. Just saying... [[User:Anniemod|Annie]] 23:20, 18 December 2018 (EST)
 +
 +
:::: I wonder how it'd look to have both external IDs and verifications in the same section. Some sources of data would be numberable, some verifiable, and some both; some numbers would be linking and others not. Would just need suitable design to be legible. --[[User:Vasha77|Vasha (cazadora de tildes)]] 23:32, 18 December 2018 (EST)
 +
 +
::::: I have just deployed a couple of cleanup reports to look for discrepancies between OCLC verifications and External IDs. It's a good example of how the two types of data are related.
 +
 +
::::: Having said that, the two sections currently capture somewhat different types of data. Obviously, the External ID section captures linked IDs, which is very useful. On the other hand, the Secondary Verifications section lets you choose "N/A", which the External IDs section doesn't support at this time. It also records the date of the verification and the name of the verifier, which can ''not'' be changed except by the verifier. Also, unlike External IDs, verifications can be added without moderatorial oversight. I have also noticed that some editors become attached to their verifications.
 +
 +
::::: I think tighter integration between External IDs and secondary verifications is worth considering. We just need to figure out how to reconcile the differences that I outlined in the previous paragraph. [[User:Ahasuerus|Ahasuerus]] 19:48, 19 December 2018 (EST)
 +
 +
:::::: The two don't have to be "linked" in order to be displayed together; it could be more like two parallel columns --perhaps start the left column with external IDs that don't have verifications, then begin a column of verifications on the right, with matching numbers associated on the appropriate line on the left. Just a thought.
 +
 +
:::::: As for better data entry linking, one possibility would be to have a space to enter an associated number on the 2ndary verification form (OCLC having a "+" for multiple numbers). The numbers would be sent to a moderated submission but the verifications would just go through automatically.  --[[User:Vasha77|Vasha (cazadora de tildes)]] 20:08, 19 December 2018 (EST)
 +
 +
::::::: I've been reading through the historical material (well, tried to), and it seems to me the current dispute could be solved by adding non-linking external ID's. Why not be pragmatic, and implement the 2nd proposal from Ahasuerus (ie Modify the logic behind External IDs to allow non-linking IDs)? It wouldn't really change anything from the current practice. After all, we're already adding oclc's and check the corresponding verification flag. I can't imagine that that would be a lot of effort (but what do I really know about coding the ISFDB, right? :)). Granted, that wouldn't all that be efficient, but hey, it would be a start and better than what we have now. As for the integration of verification and referencing, yes that could (should?) be done, but as a future enhancement as I'm sure that that would cost considerably more dev'pment effort.
 +
::::::: Again, if this non-linking ext ID thingy can be implemented 'quickly', I believe it'd bring back tranquillity to the community (or at least has the potential to), don't you think? [[User:MagicUnk|MagicUnk]] 06:27, 20 December 2018 (EST)
 +
 +
:::::::: There is always a balance between:
 +
::::::::* going after the "low-hanging fruit" which can be done quickly but may have to be reworked later on, and
 +
::::::::* implementing a long-term solution which takes longer to implement but is more likely to be permanent
 +
:::::::: An important factor to consider is whether a short-term solution would require more work down the road once a permanent solution is put into place. For example, the way we handled non-English titles prior to 2011 required a complete revamp once language support was added.
 +
:::::::: In this case allowing non-linking External IDs for Reginald, Bleiler, etc appears to be a low-risk proposition. Even if we end up implementing a different solution at some future point, it should be easy to move structured IDs to a different field(s).
 +
:::::::: In addition, we may want to have support for non-linking External IDs for other reasons. For example, if an external database were to go off-line, our links would become dead and would need to be deactivated. We wouldn't want to delete the IDs in case the site is eventually resurrected, but there are examples of bibliographic sites getting merged (like [https://en.wikipedia.org/wiki/Shelfari Shelfari]) or becoming frozen (like [http://www.theeuropeanlibrary.org/tel4/ the European Library].) Conversely, it's possible that some secondary sources may become available online at some point in the future.
 +
:::::::: For these reasons I think it would be worth adding support for non-linking External IDs sooner rather than later. We currently have around 4,000 Reginald IDs in Notes. It would be better to migrate them to a separate field while the number is still manageable. I will copy this proposal to the Community Portal where more editors will have a chance to eyeball it. [[User:Ahasuerus|Ahasuerus]] 16:21, 20 December 2018 (EST)
 +
 +
:::::::::Two comments:
 +
:::::::::1. The suggested cleanup report looking for gaps makes sense for the Reginald, though we wouldn't catch variant titles that have an alphabetic suffix, which the proposal seems to be aware of.  For the Bleiler indexes, this makes less sense.  Bleiler indexes both books (novels, chapbooks, collections and anthologies) and stories.  While the stories generally give their first or first few magazine appearances, I don't think it would be appropriate to add the catalog number to the magazine.  If we were to do so, there are some magazine issues that would need to hold several catalog numbers.  Those numbers are more title based by our definition.  Consequently, gaps in numbering from publication records would be expected.  As would duplicates (for books), as sometimes several editions are listed under a single catalog number. --Ron ~ [[User:Rtrace|Rtrace]]<sup>[[User talk:Rtrace|Talk]]</sup> 21:40, 20 December 2018 (EST)
 +
 +
:::::::::: Thanks for the clarification! Since different references have different numbering schemes, I assume that the projected cleanup reports will have to be reference-specific. Some will be limited to looking for duplicate IDs (and support the "ignore" functionality) while certain others will also look for duplicates. [[User:Ahasuerus|Ahasuerus]] 13:09, 22 December 2018 (EST)
 +
 +
:::::::::2. The Bleilers that contain catalog numbers are [http://www.isfdb.org/cgi-bin/title.cgi?102822 Supernatural Fiction], [http://www.isfdb.org/cgi-bin/title.cgi?1280738 The Early Years] and [http://www.isfdb.org/cgi-bin/title.cgi?1280740 The Gernsback Years].  Neither [http://www.isfdb.org/cgi-bin/title.cgi?187785 Bleiler78] nor its [http://www.isfdb.org/cgi-bin/title.cgi?102826 precursor] number their entries.
 +
::::::::: Thanks. --Ron ~ [[User:Rtrace|Rtrace]]<sup>[[User talk:Rtrace|Talk]]</sup> 21:40, 20 December 2018 (EST)
 +
 +
=== Capturing Non-Linking Secondary IDs in a Structured Way -- Proposal ===
 +
 +
Based on the discussion above, I would like to propose that we add non-linking IDs like Reginald-1, Reginald-3 and (some?) Bleilers to the list of supported External ID Types. It would require some changes to the software, but I believe that it shouldn't be too difficult to do. [[User:Ahasuerus|Ahasuerus]] 16:55, 20 December 2018 (EST)
 +
 +
: I strongly agree with the proposal. [[User:Anniemod|Annie]] 17:15, 20 December 2018 (EST)
 +
 +
:: Agree. [[User:MagicUnk|MagicUnk]] 17:48, 20 December 2018 (EST)
 +
 +
::: Agree also. --[[User:Vasha77|Vasha (cazadora de tildes)]] 18:09, 20 December 2018 (EST)
 +
 +
::::I also support this.  --Ron ~ [[User:Rtrace|Rtrace]]<sup>[[User talk:Rtrace|Talk]]</sup> 21:20, 20 December 2018 (EST)
 +
 +
::::: Yes, please. [[User:Stonecreek|Stonecreek]] 01:25, 21 December 2018 (EST)
 +
 +
:::::: Agree. [[User:Rudam|Rudam]] 08:28, 21 December 2018 (EST)
 +
 +
:::::::I support this. --[[User:Chris J|Chris J]] 15:35, 21 December 2018 (EST)
 +
 +
::::::::Pile-on support. ···[[User:Nihonjoe|<font color="darkgreen">日本穣</font>]] · <small>[[Special:Contributions/Nihonjoe|<font color="blue">投稿</font>]] · [[User talk:Nihonjoe|Talk to Nihonjoe]]</small> 16:10, 21 December 2018 (EST)
 +
 +
:::::::::Another yes from me. [[User:PeteYoung|PeteYoung]] 20:17, 21 December 2018 (EST)
 +
 +
=== Support for Non-Linking Secondary IDs -- Outcome ===
 +
 +
Consensus reached. {{FR|1236}} "Allow non-linking External IDs" has been created. [[User:Ahasuerus|Ahasuerus]] 13:05, 22 December 2018 (EST)
 +
 +
== How to handle PODs? ==
 +
 +
Hi, I was wondering whether Open Road Media is a POD publisher? I have The Goblin Reservation from {{a|Clifford D. Simak}}, and on the last page there are the following codes: BVHW07s0858081018, and, 529577BV00001B/146/P. From the former I deduce a printing date of 2018-10-08, and the second indicates POD (it has the same structure as confirmed Amazon PODs). Correct?
 +
My second question is, how do we best enter and verify POD publications, as there seems to be no guidance available yet for PODs? Obviously, a pub per print date (when available) is impractical. Would we update a pub, and add printing info like the codes above in one single pub, referring to the PVer and his copy? [[User:MagicUnk|MagicUnk]] 04:39, 25 December 2018 (EST)
 +
 +
: Open Road is a POD publisher, yes. They are doing a lot of reprints (they started only as e-book publisher I think and then just branched out). The last time we had this discussion, we kinda decided to consider all printings of PODs the same publication as long as nothing but those codes and dates change (same cover, same author version and so on). Adding the codes in the publication does not make sense - there may be thousands of them for popular books... I think we are still waiting and watching the situation. When I am cataloging POD books, I mention in the notes that it is a POD book but that's pretty much it. [[User:Anniemod|Annie]] 04:56, 25 December 2018 (EST)
 +
 +
:: There's the remaining question of printing dates; do we want to capture the printing date, and other related info, of verified PODs, as the verified copies are limited in number (for now). It would have the advantage of gathering data and keeping it with the publication. We can always go back and clean up later when we settle on how to handle PODs, right? See also the Binti case below. [[User:MagicUnk|MagicUnk]] 04:55, 27 December 2018 (EST)
 +
 +
=== Binti ===
 +
There's also the Binti case (and maybe other TOR chapbooks too). So far, the following information is available:
 +
 +
* {{p|529388|Binti}} - chapbook with standard print runs (first, fifth, eight, tenth, thirteenth have been listed so far). No evidence of POD. Nihonjoe and/or Hitspacebar may want to chime in with additional info on their copies.
 +
* {{p|595725|Binti: Home}} - chapbook, all seem to be PODs, but with different 'characteristics'. The following info is available:
 +
** POD with ''First edition: January 2017'', and ''P1'' on the copyright page, and date and sequence numbers and 'Printed in...' on the last page (MagicUnk and Bluesman's copies)
 +
** POD without any of the numbers, nor ''P1'' on its copyright page, only 'Printed in the USA' on back cover (Hitspacebar's copy) <br>I've [http://www.isfdb.org/wiki/index.php/User_talk:Nihonjoe#Binti:_Home_redux asked Nihonjoe] to check his copy.
 +
* {{p|640962|Binti: Night Masquerade}} - novel, seems to be a mixture of standard print-runs, and POD. Following info available so far:
 +
** First printing, full number line, no POD info whatsoever (MagicUnk's copy)
 +
** POD info, such as "Printed by BoD in Norderstedt, Germany" on top and has a QR code on the lower left corner - not sure whether there's the date code and/or sequence number too (Hitspacebar's copy)
 +
 +
As stated by Jens, it looks like at least TOR does a mixture of regular print runs and print-on-demand. I would suggest to make that distinction in the pub records too: ie have at least two records to distinguish POD from regular printings:
 +
* a record for all PODs, and - as Jens put it ''"I guess we should record in the note of the current record that copies are maybe POD and, as long as we can't clearly distinguish the different prints, also add all information (like the "P1" and the long sequence of letter numbers on the last page) to the note. Jens Hitspacebar 07:17, 31 March 2018 (EDT)"''
 +
* and a record for the regular print runs.
 +
Does this makes sense? [[User:MagicUnk|MagicUnk]] 04:55, 27 December 2018 (EST)
 +
 +
== Performance - 2018-12-26 ==
 +
 +
I am aware of the performance issues that we have been experiencing today. As near as I can tell, they are being caused by a number of robots (Google, Bing, SemrushBot, etc) crawling the site at the same time. I am working on it. [[User:Ahasuerus|Ahasuerus]] 18:46, 26 December 2018 (EST)
 +
 +
: I have identified the culprit. A rogue bot was running a custom Advanced Title Search which was designed to scrape a subset of our titles. It was also hiding that it was a robot. A rather odd thing to do considering that our backups are publicly available, so there is no need to scrape Web pages.
 +
 +
: I'll create an SR to restrict Advanced Search selection criteria. Sorry about the aggravation. [[User:Ahasuerus|Ahasuerus]] 20:27, 26 December 2018 (EST)
 +
 +
:: Advanced Search is visible from pretty much any page, you need to know about the archives (or search the wiki) to find them. So not really surprising that someone will decide to go with Advanced Search... Thanks for finding the problem quickly :) [[User:Anniemod|Annie]] 20:46, 26 December 2018 (EST)
 +
 +
::: Good point. It may be best to add a note to the Advanced Search Page. [[User:Ahasuerus|Ahasuerus]] 20:57, 26 December 2018 (EST)
 +
 +
:::: Is it back to doing it again? It seems that some queries are slowish again - almost the same way they slow down when the nightly reports run and how it felt earlier today. [[User:Anniemod|Annie]] 21:43, 26 December 2018 (EST)
 +
 +
::::: Yes, that robot is back and running the same search. It's up to record 131,000 now. I'l see if I can do something about it in the short run. [[User:Ahasuerus|Ahasuerus]] 21:59, 26 December 2018 (EST)
 +
 +
:::::: I have tweaked our access settings to ban this particular bot temporarily. [[User:Ahasuerus|Ahasuerus]] 22:33, 26 December 2018 (EST)
 +
 +
(unindent)Is the not so intelligent bot back? [[User:Anniemod|Annie]] 18:36, 28 December 2018 (EST)
 +
 +
: It is. It's also using VPNs to avoid getting blocked. I am looking into. [[User:Ahasuerus|Ahasuerus]] 18:43, 28 December 2018 (EST)
 +
 +
: P.S. The underlying problem is that our Advanced Search software lets users create almost arbitrarily complex queries which then require traversing and examining hundreds of thousands of title records. While a query is running, all title records are locked, which makes all Web pages that display titles pause for up to 10 seconds.
 +
 +
: Ideally, we would change the Advanced Search software not to lock records while running. Unfortunately, our database settings do not support this functionality.
 +
 +
: Alternatively, we could impose additional restrictions on Advanced Search selection criteria, but it would make Advanced Search less useful. I'll need to think about the trade-offs involved. [[User:Ahasuerus|Ahasuerus]]
 +
::Have a separate Advanced Search for logged in and non-logged in users? The non-logged ones limits the criteria and the logged in one doesn't? --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 18:54, 28 December 2018 (EST)
 +
 +
::: An interesting thought. Thanks. [[User:Ahasuerus|Ahasuerus]] 18:57, 28 December 2018 (EST)
 +
 +
:::: I'm not fond of that idea--why should one bad actor force everyone to have to log in in order to search properly? --[[User:Vasha77|Vasha (cazadora de tildes)]] 10:54, 29 December 2018 (EST)
 +
 +
:::::Several of the sites that I use regularly require a log in to use advanced search, possibly for the same reasons.--[[User:Rkihara|Rkihara]] 11:48, 29 December 2018 (EST)
 +
:::::Because it's better than everyone being impacted as is the current case. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 12:28, 29 December 2018 (EST)
 +
::::: Plus our accounts are free and do not require an email or verification - anyone that really wants to search can create one in seconds. Google search does not require one, simple search and even some advanced search options will still remain open. And we do not have unlimited resources and allowing the server to go down just because we are trying to be nice is a bad idea. [[User:Anniemod|Annie]] 14:31, 29 December 2018 (EST)
 +
:::: Can bots have logins? ../[[User:Holmesd|Doug H]] 14:53, 29 December 2018 (EST)
 +
::::: Technically? Yes - which is why so many sites use CAPCHA and similar things (among other reasons). But most bad actors tend to move on when they are asked to have a login as opposed to coding a login into the bot. Although if they are really persistent, coding the bot to create a new account and then do the search is not going to be too hard (and it is being done daily on sites that require a login for everything). [[User:Anniemod|Annie]] 15:02, 29 December 2018 (EST)
 +
::::::Also can add a requirement to have a handful of approved edits before enabling the more complex features. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 16:32, 29 December 2018 (EST)
 +
 +
(unindent)And it seems like it is a very persistent bot - the site is sluggish again... [[User:Anniemod|Annie]] 14:34, 29 December 2018 (EST)
 +
: It was active earlier today, around 8-9am EST, and kept switching IP addresses -- I had to play whack-a-mole with it for an hour. It's usually active a few times a day, usually in the morning and in the early evening EST. I suspect that it requires manual intervention to change IP address and the operator is only available sporadically. It seems to be on hiatus again. [[User:Ahasuerus|Ahasuerus]] 15:17, 29 December 2018 (EST)
 +
:: Yeah, it is back to normal - the site was a lot slower a few minutes before I posted above (almost as bad as it was when you were chasing that bad cleanup report a few weeks ago - definitely slower than on the last 2 days -  or I just happened to be on the same titles...). I just wish we could just point the guy/gal to the archives... [[User:Anniemod|Annie]] 15:24, 29 December 2018 (EST)
 +
 +
::: I need to add a link to the backups to the Advanced Search page. Too many balls in the air at the moment... [[User:Ahasuerus|Ahasuerus]] 15:28, 29 December 2018 (EST)
 +
::::At this point, probably wouldn't be seen as they already have the parsing logic and probably not looking at the page itself. Though of course, you could always tweak the layout to break their parser so they would have to check. Can you tell from the queries whether they working their way through something that should eventually end? Or are they just being intentionally disruptive? --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 16:32, 29 December 2018 (EST)
 +
 +
::::: The query says "Find all titles that are not ESSAY or INTERIORART and that were first published between 1900 and 1999; sort by date." They have scraped 245K out of 562K eligible titles, so they are almost 50% there. Of course, it's possible that they will then change their query to cover 2000-2019 titles. [[User:Ahasuerus|Ahasuerus]] 16:54, 29 December 2018 (EST)
 +
 +
(unindent) The Advanced Search page has been linked to [[ISFDB Downloads]]. [[User:Ahasuerus|Ahasuerus]] 15:44, 31 December 2018 (EST)
 +
 +
== Rod Serling ==
 +
 +
(copied from [[Talk:Awards]])
 +
 +
The Rod Serling Memorial Foundation issues annual awards (complete with plaque!)  Whom would I petition to have this award added?  Thank you! {{unsigned|Galacticjourney}}
 +
 +
: According to the [https://www.ithaca.edu/rhp/serling/ award page]:
 +
 +
:* The Rod Serling Award for Advancing Social Justice Through Popular Media honors a contemporary media industry professional whose work shines the light on prejudice, inequality, and evolving social norms.
 +
 +
: Awardees:
 +
 +
:* 2015/2016: [https://www.ithaca.edu/rhp/serling/2016/ David Simon], a TV writer/producer none of whose TV credits appear to be speculative. Not in the ISFDB.
 +
:* 2016/2017: [https://www.ithaca.edu/rhp/serling/kenya/ Kenya Barris], a TV producer/writer none of whose TV credits appear to be speculative. Not in the ISFDB.
 +
:* 2017/2018: [https://www.ithaca.edu/rhp/serling/kelley/ David E. Kelly], a TV producer/director none of whose TV credits appear to be speculative. Not in the ISFDB.
 +
:* 2017/2018: [https://www.ithaca.edu/rhp/serling/delia/ Bill D'Elia], a TV producer/writer none of whose TV credits appear to be speculative. Not in the ISFDB.
 +
:* 2018/2019: [https://www.ithaca.edu/rhp/serling/lear/ Norman Lear], a TV producer/writer. His [https://www.imdb.com/name/nm0005131/ media credits are extensive], but I can't find anything speculative. We have [http://www.isfdb.org/cgi-bin/ea.cgi?151004 one essay (published in ''Omni'')] on file.
 +
 +
: Considering the fact that this award is for media (as opposed to written) work and that it's not related to SF, I don't think it falls within the scope of the project. [[User:Ahasuerus|Ahasuerus]] 15:46, 28 December 2018 (EST)
 +
 +
::I would have to agree with Ahasuerus. If anyone listed on ISFDB ever wins one, it could be placed in the bio notes on the author/artist page. ···[[User:Nihonjoe|<font color="darkgreen">日本穣</font>]] · <small>[[Special:Contributions/Nihonjoe|<font color="blue">投稿</font>]] · [[User talk:Nihonjoe|Talk to Nihonjoe]]</small> 17:24, 28 December 2018 (EST)
 +
 +
:::I think you may be looking at the wrong Serling Awards:  [http://www.rodserling.com/SerlingAward2016/serlingaward2016.html 2016] and [http://www.rodserling.com/SerlingAward2017/serlingaward2017.html 2017] :) --[[User:Galacticjourney|Galacticjourney]] 22:55, 28 December 2018 (EST)
 +
 +
:::: Oh, I see. Checking the lists of awardees, I see:
 +
 +
::::* 2016:
 +
::::** A blog about the history of science fiction with an emphasis on ''The Twilight Zone''
 +
::::** An abstract film
 +
::::** An album inspired by a ''Twilight Zone'' episode
 +
::::** A podcast inspired by ''The Twilight Zone''
 +
::::* 2017:
 +
::::** An anthology collecting 22 stories in the tradition of ''The Twilight Zone'', which we [http://www.isfdb.org/cgi-bin/title.cgi?2112267 have on file]
 +
::::** A documentary related to a ''Twilight Zone'' episode
 +
::::** A musical record inspired by ''The Twilight Zone''
 +
 +
:::: Of the 7 awards, 6 are for media works with links to ''The Twilight Zone'' and one is for an anthology of stories related to ''The Twilight Zone''. Since only one of the awards is for written speculative fiction, I think the best approach would be to document the award in that record's Note field. [[User:Ahasuerus|Ahasuerus]] 08:41, 29 December 2018 (EST)
 +
 +
== Galactic Journey ==
 +
 +
We have a new editor that would like to add the [http://galacticjourney.org Galactic Journey] as a web fanzine. It does not appear to me to meet our online periodical criteria. However, it was nominated for Hugo in the fanzine category this year. As such, I would like to get a wider opinion than basing it solely on mine. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 20:42, 28 December 2018 (EST)
 +
 +
::The good [[User:JLaTondre|JLaTondre]] invited me to join the discussion.  The Journey won the Serling Award in 2016 and was a Hugo finalist in 2018.  There are some twenty staff associated with the organization, many of whom are professional SFF authors, and articles are published every other day.  It is at least as notable as some of the fanzines currently listed on ISFDB.  Thank you for your consideration! :) --[[User:Galacticjourney|Galacticjourney]] 22:06, 28 December 2018 (EST)
 +
 +
:::It seems this should be "in" under the ''Online publications available exclusively as a Web page, but only if: ... shortlisted for a major award'' clause.  How exactly to fit a blog-style publication into our data model is a wee bit of a challenge.  Maybe treat each post as an "issue", along the lines of how we'd treat a daily print periodical?  There are post-specific links, and each post has a date and author credit.  How we'd link awards that are for the entire "publication", I don't know; I suppose we could make a collection to represent the entire year and link the award to that.  --[[User:MartyD|MartyD]] 12:33, 29 December 2018 (EST)
 +
::::That clause though is under the fiction heading. I'm not seeing any fiction for this site. Seems to be mainly reviews and commentary? --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 12:42, 29 December 2018 (EST)
 +
:::::There are a thousand articles at the Journey...that'd be a bit of a headache. :)  Maybe just an annual entry with notations as to awards won that year?  You are correct that there is no fiction, except that the whole thing is somewhat fictitious (it's a fanzine written as if by people living 55 years ago).  I do greatly appreciate your stretching brains to figure out how to make it fit! :) --[[User:Galacticjourney|Galacticjourney]] 15:57, 29 December 2018 (EST)
 +
 +
As there has been limited discussion, I have released my hold on this record. I'll let another moderator make the decision. --&nbsp;[[User:JLaTondre|JLaTondre]] ([[User talk:JLaTondre#top|talk]]) 19:13, 4 January 2019 (EST)
 +
 +
== More Charles McCarry ==
 +
 +
I love the novels of Charles McCarry, a great thriller/spy/politico/alternate-universe writer. We currently have a listing for him with, I think, five "Christopher Series" works listed. There are at least another four and maybe five that fall within that description, plus at least one novel that is clearly science fiction. I'll start putting these in as I get around to it. [[User:Hayford Peirce|Hayford Peirce]] 10:16, 29 December 2018 (EST)
 +
 +
== The Italian edition of my novel Napoleon Disentimed is NOT a serial ==
 +
 +
For some reason this novel is listed as being a serial. See http://www.isfdb.org/cgi-bin/title.cgi?1034444. I just pulled down my copy from the shelves and it is exactly as listed here, Urania 1135, Complete Novel, etc., but it is a stand-alone issue, with no other stories or anything else in it. In other words, this edition looks *exactly* like the publication of an entire novel. As I've only just returned to this site after being away for a number of years, I'm not sure what to do about this, so I'm bringing it to your attention here. If there is some other place on the site that I should have used, please let me know. Thanks! [[User:Hayford Peirce|Hayford Peirce]] 12:29, 29 December 2018 (EST)
 +
 +
: You've just discovered one of the quirks of this database. It was decided long ago that we would never assign anything in a magazine the title type NOVEL--instead, when a novel appears in a magazine, it has the title type SERIAL, whether it is published in several parts or just one. See [[Help:Use of the SERIAL type#"Complete Novel" rule]] for a discussion of the reasons behind this decision. --[[User:Vasha77|Vasha (cazadora de tildes)]] 12:42, 29 December 2018 (EST)
 +
 +
::Cross-posted with Vasha's much more succinct response above.  In case any of this detail is helpful:  If a novel is printed in a magazine, we consider it a "serial", even if printed in its entirety in a single issue, with no other content.  That is still technically an issue of the magazine, containing the novel, rather than the novel's publication as a "book".  We then make a variant of that "serialization" title to a non-serial title, which ultimately shows where the work was published in magazines and where it was published as books.  You can see the result [http://www.isfdb.org/cgi-bin/title.cgi?8099 here].  The presentation in the Fiction Series section [http://www.isfdb.org/cgi-bin/ea.cgi?1223 here] is a little clunky with the combination of '''Serialization:''' and '''Translation:''' and lack of indentation, but still seems to convey the proper information -- the Italian translation appeared as a complete novel in a magazine.  It all looks ok to me.  What problem is it causing? --[[User:MartyD|MartyD]] 12:47, 29 December 2018 (EST)
 +
 +
:::Thanks for all the above info. Until now I had no idea that Urania was a magazine and not a book series. No problems involved, of course, at least not after knowing the above. [[User:Hayford Peirce|Hayford Peirce]] 13:58, 29 December 2018 (EST)
 +
 +
== Adding External ID for the Belgische Bibliografie? ==
 +
 +
I recently submitted a number of pubs of Belgium publishers to add price in Belgium francs and added the URL of the source (De Belgische Bibliografie) in the notes. It then occurred to me that that is rather stupid as we (well, that's Annie actually :) recently finished cleaning up the notes and moved OCLC links to the External ID field. Is it quick to do to add these permalinks for the ''De Belgische Bibliografie/La Bibliographie de Belgique''? If so, I'll refrain from further updates until the External ID has been added. Example: https://opac.kbr.be/Library/doc/SYRACUSE/15789982/. The External ID is the number at the end of the URL. [[User:MagicUnk|MagicUnk]] 15:02, 29 December 2018 (EST)
 +
 +
: Adding a new External ID Type is fairly straightforward. Are we sure that the URL scheme is stable? [[User:Ahasuerus|Ahasuerus]] 15:31, 29 December 2018 (EST)
 +
 +
:: I's say, yes, it is stable. If you hover over the little chain link to the right of the example above, the tooltip text says ''permanent link (new window)''. [[User:MagicUnk|MagicUnk]] 15:55, 29 December 2018 (EST)
 +
 +
::: That should be good enough for our purposes. {{FR|1241}}, "Create a new External ID Type for De Belgische Bibliografie", has been created. [[User:Ahasuerus|Ahasuerus]] 16:12, 29 December 2018 (EST)
 +
:::: Make sure we have a matching template - we missed that for a few of the External IDs. :) [[User:Anniemod|Annie]] 16:22, 29 December 2018 (EST)
 +
 +
::::: Oh, right. What should we call it? [[User:Ahasuerus|Ahasuerus]] 16:43, 29 December 2018 (EST)
 +
 +
:::::  The official name (in two of the official languages) is "Bibliothèque royale de Belgique"/"De Koninklijke Bibliotheek van België. With the site being kbr.be, we kinda have a choice. If noone else has a preference, KBR sounds good to me - thus not chosing between the language versions (BRB abd KBB)... Or we can go with BB which will be language agnostic but will be very very confusing with the other external identifiers (in my humble opinion). [[User:Anniemod|Annie]] 16:54, 29 December 2018 (EST)
 +
 +
:::::: (after edit conflict) Small tidbit of info. Since Belgium is a bilingual country the name of the bibliography is to be in Dutch and French, so it's ''De Belgische Bibliografie/La Bibliographie de Belgique'' (actually Belgium is trilingual as German is the third official language, spoken in the east of the country near the German border). There seems to be no official abbreviation. We could use ''BB'', which would nicely fit both Dutch '''and''' French. [[User:MagicUnk|MagicUnk]] 16:55, 29 December 2018 (EST)
 +
::::::: After reading Annie's post, KBR sounds good too. While KBR references the Royal Library instead of the bibliography, it would solve the confusion with other Ext ID's when using ''BB''. Or we could have BeBiBe ... :-) [[User:MagicUnk|MagicUnk]] 17:00, 29 December 2018 (EST)
 +
 +
:::::::: KBR works for me. If there are no objections, I will implement it once I wrap up Fixer's submissions for the month. 57 ISBNs to go... [[User:Ahasuerus|Ahasuerus]] 09:50, 30 December 2018 (EST)
 +
::::::::: Sure, np. [[User:MagicUnk|MagicUnk]] 11:22, 30 December 2018 (EST)
 +
 +
(unindent) KBR has been added to the list of supported External Identifier Types. A matching linking template has been added. If you run into any issues, please let me know. Happy New Year! [[User:Ahasuerus|Ahasuerus]] 18:01, 31 December 2018 (EST)
 +
:: Thanks Ahasuerus. Mosr appreciated! [[User:MagicUnk|MagicUnk]] 04:06, 1 January 2019 (EST)
 +
 +
: Thanks! [http://www.isfdb.org/cgi-bin/note_search_results.cgi?OPERATOR=contains&NOTE_VALUE=kbr.be 31 publications] have the direct link. I will clean them out and move the IDs to their new house :) [[User:Anniemod|Annie]] 18:21, 31 December 2018 (EST)
 +
:: 30 converted, 1 remaining that is not like the others. I will look at it later unless someone can figure it out faster :) [[User:Anniemod|Annie]] 18:47, 31 December 2018 (EST)
 +
 +
::: You're too quick Annie, you beat me to it :). Thanks for the conversion. I'll have a look at the remaining one. If you could provide me with the pub reference? [[User:MagicUnk|MagicUnk]] 04:06, 1 January 2019 (EST)
 +
 +
:::: I just happened to be around :) The "31 publications" link in my previous message now points to the only remaining one but here is the [http://www.isfdb.org/cgi-bin/pl.cgi?698644 direct link] as well :) [[User:Anniemod|Annie]] 04:45, 1 January 2019 (EST)
 +
::::: Submitted the fix! [[User:MagicUnk|MagicUnk]] 05:05, 1 January 2019 (EST)
 +
 +
(unindent) Now that the dust settled, can we add KBR to [http://www.isfdb.org/cgi-bin/edit/cleanup_report.cgi?244 this report]? [[User:Anniemod|Annie]] 16:09, 3 January 2019 (EST)
 +
 +
: Done! [[User:Ahasuerus|Ahasuerus]] 17:49, 3 January 2019 (EST)
 +
 +
== Belgium Francs - abbreviation? ==
 +
 +
Related question: what abbreviation should I use for Belgium Francs? I've browsed the internet, and a number of [https://en.wikipedia.org/wiki/Belgian_franc different options] are available: the ISO code ('''BEF'''), or alternatively '''Bfr.''' ? I've also come across simply '''fr.''', or '''BFR''', or '''BFr.''' ...? [[User:MagicUnk|MagicUnk]] 15:02, 29 December 2018 (EST)
 +
 +
:There's no real consistency.  You should not use BEF (the ISO code).  We intend that the "symbol" be used.  I think for francs, this is "fr", although I know we have extensive use of "F".  The "$" case provides precedent for applying a country-specific modifier on what would be an ambiguous symbol (e.g., "A$" for Australian dollar prices).  So I'd be inclined to use "Bfr".  And we include a space after any non-symbolic currency "symbol", so, for example, "Bfr 123". --[[User:MartyD|MartyD]] 17:58, 30 December 2018 (EST)
 +
 +
:: Thanks. That makes sense. Would we benefit from keeping a list of currency symbols in the help text? We would then be able to, say, 'officialize' use of C$ for Canada, Bfr for Belgium, etc. Anyone else any thoughts? [[User:MagicUnk|MagicUnk]] 03:53, 31 December 2018 (EST)
 +
 +
::: The list of the more popular ones (when the help page was written anyway) is already [http://www.isfdb.org/wiki/index.php?title=Template:PublicationFields:Price there] - including the  Canadian dollar. This is the help page for the price field - there is a lot of interesting information in these help pages even for fields taht appear clear. Adding some new currencies to the list is probably a good idea :) [[User:Anniemod|Annie]] 04:16, 31 December 2018 (EST)
 +
 +
:::: Ah, yes... Would it be OK to add Bfr and ƒ (for Dutch Guilders) to the help text? [[User:MagicUnk|MagicUnk]] 06:50, 31 December 2018 (EST)
 +
 +
::::: Spanish peseta is Pta, Mexican dollar is Mx$. Question: since Argentinian peso is Ar$, should we change the Australian dollar to Au$? That is the form you always see in actual use, anyway. --[[User:Vasha77|Vasha (cazadora de tildes)]] 15:13, 31 December 2018 (EST)
 +
 +
:::::: Changing the Australian dollar is a bad idea -- we have thousands of publications with it and everyone is used to using it. So no, I will vote strongly against changing it. Otherwise we should change the good old US dollar to U$ or something :) Let's leave the established symbols alone. [[User:Anniemod|Annie]] 18:19, 31 December 2018 (EST)
 +
 +
::::::: Once we start working on adding support for multiple prices per publication ({{FR|1158}}), it will be a good time to revisit the issue of currency symbols. The proposed redesign will make them table-driven, so changing currency signs will require a single database update per currency. [[User:Ahasuerus|Ahasuerus]] 18:26, 31 December 2018 (EST)
 +
 +
:::::::: True. I was commenting on the situation now when people need to remember how to write certain currency symbols. If and when we redesign the whole thing, we can discuss again what/how we want to be shown. But swapping a well-established symbol that is used a lot just does not make sense. :) [[User:Anniemod|Annie]] 18:30, 31 December 2018 (EST)
 +
 +
::::::::: I went ahead and updated the help text with Bfr, ƒ, Pta, Mx$, and Ar$ examples. Let me know if it isn't acceptable. <br> Also, I have been thinking about pubs that have more than one price, and how we can ease the migration effort once {{FR|1158}} becomes available. Currently we record the primary price (ie price in country of origin) in the price field, and the secondary prices in the notes field. Would it be a good idea to have templates for the most common currencies that show up in the notes, such as $, C$, A$, £, Bfr, ƒ,..., and also request editors to effectively start using them? If we would start using templates, I'm sure that the conversion would become much easier, no? [[User:MagicUnk|MagicUnk]] 04:58, 1 January 2019 (EST)
 +
 +
== a "known phishing site" ==
 +
 +
When I come to ISFPB from my destop screen, I go first to the Home Page. Then I click on ISFDB Wiki. From there I go to Community Portal, which is where I'm writing this. If I have just done this for the time, ie, starting with the Home Page from my computer desktop, a small box pops up on the lower right of my screen courtesy of Emsisoft, my excellent Anti-Virus program.
 +
 +
Its mysterious message is, more or less: "www.audible.co.jp is a known phishing site and we have blocked it".  After about ten seconds the box slides away and I am unable to get a screen shot of it to show you.
 +
 +
As far as I know, Emsisoft is an *excellent* AV program, one that is both alert and yet NOT overly intrusive.
 +
 +
Is there some reason that it seems to feel that some aspect of ISFDB is a phishing operation? It's very, very rare that I get a message like this. It's all very mysterious to me! [[User:Hayford Peirce|Hayford Peirce]] 15:37, 30 December 2018 (EST)
 +
 +
: There is a reference to audible.co.jp in [http://www.isfdb.org/wiki/index.php/ISFDB:Community_Portal#Audible.co.jp_ASINs this] discussion on the page. Your antivirus must be detecting the presence of links to the site. ../[[User:Holmesd|Doug H]] 15:56, 30 December 2018 (EST)
 +
 +
:: According to [https://www.pcmag.com/review/364261/emsisoft-anti-malware this PCmag.com review], Emsisoft offers "excellent" malware protection but "dismal" phishing protection. It detected only 18% of the phishing sites that PCmag tried in their October test.
 +
 +
:: Another thing to keep in mind is that the ISFDB allows links to arbitrary Web pages in notes and "Web Page URL" fields. Granted, all submissions are reviewed by moderators and are most likely safe at the time when they are approved. (Also, submissions by new editors are flagged.) However, the internet is a rapidly changing environment. Author-run sites are frequently abandoned and then purchased by third parties, some of them malicious. When it happens, our links can be affected. [[User:Ahasuerus|Ahasuerus]] 17:11, 30 December 2018 (EST)
 +
 +
:::Thanks for the lucid explanation. I have noticed before that Emsisoft doesn't seem to be up to speed with phishing in general. I THINK I can tell it to ignore this particular one, though. If I can, I'll do so. [[User:Hayford Peirce|Hayford Peirce]] 17:28, 30 December 2018 (EST)
 +
 +
== Support for non-linking External ID Types added ==
 +
 +
As per [[ISFDB:Community_Portal#Capturing_Non-Linking_Secondary_IDs_in_a_Structured_Way|this discussion]], the software has been updated to allow non-linking External ID Types. As expected, it was a fairly straightforward change.
 +
 +
The next step is to decide which non-linking External ID Types we want to add at this time. Here are the current candidates:
 +
 +
* [[Reference:Reginald1|Reginald-1]]
 +
* [[Reference:Reginald3|Reginald-3]]
 +
* [[Reference:BleilerSupernatural|Everett F. Bleiler's "The Guide to Supernatural Fiction" (1983)]]
 +
* [[Reference:BleilerEarlyYears|Everett F. Bleiler and Richard Bleiler's "Science-Fiction: The Early Years" (1991)]]
 +
* [[Reference:Bleiler1|Everett F. Bleiler and Richard Bleiler's "Science-Fiction: The Gernsback Years" (1998)]]
 +
 +
Anything else? [[User:Ahasuerus|Ahasuerus]] 18:42, 31 December 2018 (EST)
 +
: These look good to me for a start - and I cannot think off the top of my head of any other IDs that I had seen often enough to consider them eligible for pulling into an ID field. [[User:Anniemod|Annie]] 16:30, 1 January 2019 (EST)
 +
 +
:: OK, I have added the 5 non-linking ID types listed above. [http://www.isfdb.org/cgi-bin/pl.cgi?312848 Here is an example of what a converted publication record looks like.] If everything looks OK, I can create new cleanup reports to facilitate the conversion process. [[User:Ahasuerus|Ahasuerus]] 22:39, 1 January 2019 (EST)
 +
 +
:::Thanks for this.  I don't know what I'm going to do with my templates now.  --Ron ~ [[User:Rtrace|Rtrace]]<sup>[[User talk:Rtrace|Talk]]</sup> 07:09, 2 January 2019 (EST)
 +
 +
:::: Hey, they served their purpose! The new cleanup report that I deployed a few minutes ago takes advantage of the fact that these IDs were entered in a semi-structured manner to facilitate the migration process.
 +
 +
:::: Once the cleanup reports are regenerated overnight, there will be 1,700+ publication records that will need to be updated. There are probably more since early on some IDs were entered in a non-structured fashion, but let's take care of the low-hanging fruit first. [[User:Ahasuerus|Ahasuerus]] 11:48, 2 January 2019 (EST)
 +
 +
(unindent) We probably should also add them to [http://www.isfdb.org/cgi-bin/edit/cleanup_report.cgi?244 this report] (with the Reginalds allowing a last alphabetical symbol) so we do not end up chasing them later when some typos happen. We probably will also want to have a check if it is in the proper range at some point (As these 5 are finite) but that is not as easy... [[User:Anniemod|Annie]] 16:11, 3 January 2019 (EST)
 +
 +
: Do we know if the 3 numbered Bleilers use purely numeric record IDs? I have the Reginalds but not the Bleilers in my collection, so I can't check. [[User:Ahasuerus|Ahasuerus]] 18:10, 3 January 2019 (EST)
 +
 +
:: OK, the two Reginalds have been added to the cleanup report. [[User:Ahasuerus|Ahasuerus]] 18:55, 3 January 2019 (EST)
 +
 +
:: I suspect that Ron's books are out in the open and he can check easily - I do not remember seeing anything but numbers in either Gernsback, or the Early Years but both of them are in a box (and I have no idea which of the many boxes...) and admittedly I was not trying to verify if there is anything else there besides numbers. [[User:Anniemod|Annie]] 22:23, 3 January 2019 (EST)
 +
 +
:::Indeed they are.  Bleiler numbers are all numeric for books.  He does list the contents by letter within each anthology/collection by letter, but we wouldn't need to add that to a publication record, so a numeric test would be fine.  --Ron ~ [[User:Rtrace|Rtrace]]<sup>[[User talk:Rtrace|Talk]]</sup> 07:05, 4 January 2019 (EST)
 +
 +
::::: Thanks for the confirmation. The cleanup reports have been updated. [[User:Ahasuerus|Ahasuerus]] 14:03, 4 January 2019 (EST)
 +
 +
::::I noticed something with [http://www.isfdb.org/cgi-bin/pl.cgi?417294 this publication].  Take a look at the first external ID which appears to have an extra space between the bullet and the number.  It's possible that this is browser specific and I'm using Firefox.  In any case, I fixed this by clearing an extra newline at the end of the notes.  I put it back, for discussion.  It's only a minor cosmetic issue, so not in any way urgent.  Thanks.  --Ron ~ [[User:Rtrace|Rtrace]]<sup>[[User talk:Rtrace|Talk]]</sup> 07:28, 4 January 2019 (EST)
 +
 +
::::: I have tried it under Firefox 64.0, Google Chrome 71.0, MS Edge 44 and IE 11 and I am not seeing the extra space. Could you please check which version of Firefox you are using? [[User:Ahasuerus|Ahasuerus]] 11:05, 4 January 2019 (EST)
 +
 +
::::::I'm also running 64.0.  A little additional testing finds that the extra space appears only from the View This Pub link from the SQL statements page.  A refresh makes things appear correctly.  Also no matter how I edit it, there appears to be one newline at the end of the note text, i.e. whether I remove the newline, or add a second one, when I go back in there appears to be a single new line at the end of the text.  Given that the display rights itself on a refresh, I wouldn't worry about it.  Also it seems that there may be some sort of cleanup of the notes field that puts a single newline in place of any trailing whitespace (I'm guessing).  If this is by design or accident, it certainly seems reasonable.  Sorry to have you chasing wild geese.  --Ron ~ [[User:Rtrace|Rtrace]]<sup>[[User talk:Rtrace|Talk]]</sup> 19:13, 4 January 2019 (EST)
 +
 +
::::::: Thanks for the additional information! I have been able to recreate the problem -- sort of. Under Firefox 64.0, the first displayed External ID is displayed with an extra space if the Notes field immediately above contains the "BREAK" template. The other tested browsers do not have this problem and even under Firefox it is somewhat inconsistent.
 +
 +
::::::: The underlying HTML code is valid as per the W3C validator, so I expect that it's an issue with Firefox 64.0. If the bug is not fixed in the next few versions, I may do more digging and try to come up with a workaround. [[User:Ahasuerus|Ahasuerus]] 21:25, 4 January 2019 (EST)

Latest revision as of 20:17, 27 June 2019

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 July - December 2018

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


Problem Identified

It looks like Annie and Marty have been able to track it down. The problem is the discrepancy between what is stated in the "From" field of the e-mail messages that the ISFDB server sends and the name of the ISFDB server. For example, when I use ISFDB mail to send an e-mail to another user, the message says "From: ahasuerus [at] email.com", but the actual sending server is "isfdb.org". When another e-mail server receives an e-mail message with this type of conflict, it becomes suspicious of it because of the long history of e-mail abuse (spam, phishing, etc.) Depending on server settings, the following happens:

  • some servers deliver the message
  • some servers flag it as "spam"
  • some servers refuse to deliver it to the addressee and simply delete it

This explains why some e-mail messages made it to the their destinations and some didn't. Next we'll need to figure out how to fix the problem... Ahasuerus 15:37, 1 July 2018 (EDT)

Changes Made

Our email settings have been tweaked. From now on, email messages sent using ISFDB mail will have "postmaster@isfdb.org" in the "From" field and the sending user's e-mail address in the "Reply-To" field. When the recipient clicks "Reply", the e-mail will be sent to the address in the "Reply-To" field.

Hopefully, this change will help reduce the number of undelivered e-mail messages. Ahasuerus 17:13, 2 July 2018 (EDT)

"Journey to the West" and Wu Cheng'en

Although 西遊記/Journey to the West is often attributed to Wu Cheng'en, that isn't certain and it was originally published without a named author, so we have its canonical author as "uncredited." Some excerpts from the novel remain on Wu's page at present. If no one has any objection, I'm going to give them all an uncredited parent title and assign them to the existing series "西遊記 / Monkey." --Vasha (cazadora de tildes) 13:36, 30 June 2018 (EDT)

Your best/latest author?

Who's the best new hard sf/space opera author you've read in the past 12 months? —The preceding unsigned comment was added by Magillaonfire (talk • contribs) .

Me, though my story isn't done yet. ;) ···日本穣 · 投稿 · Talk to Nihonjoe 15:34, 2 July 2018 (EDT)
For reference purposes, we have a list of all titles tagged "space opera" by ISFDB users. Ahasuerus 16:28, 2 July 2018 (EDT)

Looking for print run info

Hi, does anyone know how you might easily find out roughly how many copies of any particular book were ever published. —The preceding unsigned comment was added by Mjc42 (talk • contribs) .

It depends on the book. Some limited editions make this information readily available. Also, some bibliographers research publisher records and include it in their bibliographies. More recently, certain self-published authors have been known to post this information on their Web sites. Otherwise it can be difficult to find. Ahasuerus 12:12, 3 July 2018 (EDT)

The reason I ask is that I have a copy of 'OUT OF TIME ' by George Langelaan, the 1966 Four Square Books paperback collection of stories which contains Langelaan's well know story : 'The Fly'. I can't seem to find one for sale anywhere (other than my own) including bookfinder, Abebooks, Alibris etc. I get the impression that it is quite rare, but I don't really know why. —The preceding unsigned comment was added by Mjc42 (talk • contribs) .

Advanced Title Search Results and Tags and user preference

If you use Advanced Title Search and one or more of the results have too many tags, the tags column squishes the rest of the fields and takes over most of the screen. Here is an example (stolen from the original conversation here). Can we add a new user preference (similar to the "Do not display bibliographic warnings on Title pages") that controls if a user sees the tags in advanced search at all? This way if someone really does not care about the tags can stop them from cluttering the page. Annie 13:03, 3 July 2018 (EDT)

Either that, or set a hard width for the column (either a percentage or a specific pixel width). ···日本穣 · 投稿 · Talk to Nihonjoe 13:14, 3 July 2018 (EDT)
Please do not do "specific pixel width" - this will make small screens unusable - I do a lot of work on my phone and I suspect that a lot of people use it for searching. Percentage can work... Annie 14:33, 3 July 2018 (EDT)
I don't know which solution would be better, but I have created FR 1166 to make sure we that don't forget about this issue.
I suspect that using "hard column width" may result in a lot of screen real estate getting wasted due to near-empty cells in other columns, but I'll have to experiment to confirm. Ahasuerus 15:46, 5 July 2018 (EDT)

Facebook page

I made a Facebook page for ISFDB. In case anyone is interested. ···日本穣 · 投稿 · Talk to Nihonjoe 14:18, 3 July 2018 (EDT)

Nice, thanks! What sort of things are you thinking of posting on it? --Vasha (cazadora de tildes) 15:10, 5 July 2018 (EDT)
No idea. Feel free to brainstorm. Also, go like the page if you can, and share it around. Right now, it's got almost 100 people following it about two days after it was created. ···日本穣 · 投稿 · Talk to Nihonjoe 15:19, 5 July 2018 (EDT)

Slate Magazine: include their fiction under existing rules?

Slate Magazine (online, nongenre, non-issues) is running a monthly series of science fiction stories. I think these can be included in the database (and should be, because it's featuring authors like Charlie Jane Anders and Nnedi Okorafor), on the grounds of the existing rule about SFWA-qualifying markets, which Slate clearly is. --Vasha (cazadora de tildes) 18:21, 4 July 2018 (EDT)

I am not sure that it actually qualifies (do they pay 6c per word or at least $3,000 for ALL their fiction(other than reprints or serializations)? - publishing known authors does not male them eligible on its own) I cannot find any statement on their page that will make them "clearly qualifying" - can you post a link to it? Annie 19:12, 4 July 2018 (EDT)
whopayswriters.com says that they pay well and promptly but one freelancer reports being offered $100 for a 3000-word piece of investigative reporting. That site isn't a lot of help. I can't find anything official yet. --Vasha (cazadora de tildes) 19:37, 4 July 2018 (EDT)
(We were cross-posting so I will still post that:) ). This is a report from a few people what they were paid for specific pieces; it is not clear how/if they pay for the fiction (and all the fiction) - which is what SFWA is concerned about. Is there a guideline published by Slate somewhere? We are talking about the "Future Tense Fiction", right? I know that they started with stories from anthologies and not original fiction and then had some original ones (like this one but did not know that they had turned it into a monthly feature. I guess we can let them in under the "Other Qualifying Markets" (Slate being a webzine but I am not sure how much that rule apply for webzines) but will that open a door we are not ready to open? On the other hand, if New Yorker decide to publish an exclusive story on their site, that won't qualify it based on this clause. How many original stories are we talking about at the moment? Annie 20:01, 4 July 2018 (EDT)
All of the stories from this year are original. As for "opening doors we don't want to open," yes, that's potentially a problem because it is so hard to figure out whether magazines qualify. I think Slate probably does because of all the talk on the web about them being one of the best-paying places to submit writing, but if we assume Slate qualifies without knowing for certain, what else are we going to let in on the basis of assumptions? I have to agree with you, let's leave Slate out for now unless someone has an idea how to get better information. --Vasha (cazadora de tildes) 20:14, 4 July 2018 (EDT)
I couldn't see anywhere to submit to Future Tense. It may be that they are simply inviting authors who share Slate's political views to submit stories. All of the stories there seem to lean left. Regardless of that, I don't know that this would qualify even under the currently proposed expansion of scope for ISFDB. ···日本穣 · 投稿 · Talk to Nihonjoe 14:05, 5 July 2018 (EDT)
Nope, it won't - not for now anyway(single stories in a non-genre non-issues based webzine). Their only chance is under the SFWA exception - and I just cannot find enough information to prove that they are eligible under it. :) In the long run we want these stories but... baby steps and all that. Annie 14:09, 5 July 2018 (EDT)
Well, if they are any good, they will likely be reprinted in an anthology or collection at some point. ···日本穣 · 投稿 · Talk to Nihonjoe 14:53, 5 July 2018 (EDT)
It's certainly true that these days most stories which appear online get reprinted in e-books or paper books sooner rather than later. However, I recall some vignettes which didn't get reprinted until much later. Hopefully we'll address this issue during the next round of R&S discussions. Ahasuerus 15:01, 5 July 2018 (EDT)
Even if they get reprinted, we still want the first publication record eventually - we are a bibliography after all :) And yes - this kind of stories will be a prime candidate for the next wave of changes (if the current changes pass and all looks fine after that). We'll get there eventually :)Annie 15:08, 5 July 2018 (EDT)

Robert Sidney Bowen's "Dusty Ayres" novels - Looking for volunteers

As SFE3 notes, Robert Sidney Bowen's "Dusty Ayres" stories, which were originally published in the eponymous 1934-1935 pulp magazine, are "of SF interest". At this time we have only 8 of them on file.

Looking for volunteers to enter the rest of the pulp issues, flesh out our "skeleton" publications, enter the recent paperback reprints (see Amazon) and research his bio data.

Please note that SFE3 and Wikipedia differ re: his legal name and date of birth. I have sent an e-mail to Dave Langford re: SFE3's bio data, which seems to be out of date. Further research may be needed. Ahasuerus 13:25, 5 July 2018 (EDT)

Only the last 12 issues of the "Battle Birds" are eligible, right (July 1934 - July/Aug 1935 -- after the name change to "Dusty Ayres and His Battle Birds")? Annie 16:17, 5 July 2018 (EDT)
Right. AFAIK, only Bowen's "Dusty Ayres" stories were about "future war". The original "Battle Birds" version of the magazine was non-SF. Ahasuerus 16:23, 5 July 2018 (EDT)
Yeah, I've seen one of the older ones - they are a decent aviation pulp but they are not speculative in any way or form. Annie 16:31, 5 July 2018 (EDT)
I can add them later this week together with the reprints. I will see what I can do about his biography but if one of our specialists in authors research wants to do that, I will be more than happy to hand off that job :) Annie 16:17, 5 July 2018 (EDT)

Psychocrat

What is the justification for this Psychocrat as a 'series' and can anyone tell me where that name comes from? The word 'psychocrat' does not appear in either of the novels and the stories do not appear to have any relation to each other at all. SF&F-fan 14:43, 8 July 2018 (EDT)

Checking Google Books, I see the following sentence in Android in Arms (2015 edition):
  • The Mengians were the heirs of the Psychocrats, and Psychocrats were men (or emotionless superendowed likenesses of me) who admittedly knew more about the human mind and body than any scientists before or since.
That said, there are two things to keep in mind. First, a lot of Norton's books were set in the same universe. Some form clear sub-series, but there is a lot of cross-pollination. The last time we tried to sort everything out, we ended up with a collective headache.
Second, some of her books were re-edited after the end of the Cold War. For example, the "Reds" in the "Time Trader" books became "Great Russians". It's possible that the "Psychocrats" were also affected in some way. Ahasuerus 14:56, 8 July 2018 (EDT)

BAEN has indeed published those 2 novels together under the tile "Gods and Androids ", but BAEN books have many editions of completely unrelated books. I think these 2 novels should be listed as stand-alone. SF&F-fan 14:43, 8 July 2018 (EDT)

SFE3 also lists these two under the same series name, but unsure who is leading who. I'm not seeing anything that ties these two together. The Amazon Look Inside for the omnibus doesn't show a introduction or anything else that claims they are related. Additionally, Ice Crown specifically references the Psychocrats (they established the colony and the whole setup for the book) so it would be a more natural pairing with Android in Arms. -- JLaTondre (talk) 15:33, 8 July 2018 (EDT)


You are correct, Ahasuerus, J LaTondre. Thank you for the comments. I was mistaken about psychocrats not being mentioned in those books. I did check again without the case sensitive checked, and then the word did show up in "Androids at Arms", but not in "Wraiths of Time". The word doesappears in "Ice Crown", so those 2 would indeed be a better match for a 'psychocrat' sub-series.


I provided a link to a page that lists pretty much everything that belongs there. The original page did also provide some explanation about the various linkages between the books. SF&F-fan 23:34, 8 July 2018 (EDT)

Andre Norton - Forerunner Universe

Andre Norton's most important 'Universe' is the Forerunner universe. It may not be as clearly defined as Heinlein's, but it is a well acknowledged Future History.

Unlike with many other authors I do not see Andre Norton's related works grouped together. How can that be realized? I'm not familiar enough with the page editing to link groups into a larger one. Can the moderators do that?

This AMAZON page may be a guide line for the works to include. SF&F-fan 20:56, 8 July 2018 (EDT)

As I mentioned earlier, it's generally agreed upon that a lot of Norton's books were set in the same universe. Some form clear sub-series, but there is a lot of cross-pollination. The last time we tried to sort everything out, we ended up with a collective headache. As I recall, John Wenn's bibliography of Norton's works was also convoluted with multiple books belonging to multiple sub-series.
It would be great if we could find an expert who would be familiar with all of her series and sub-series and how they are linked. Ahasuerus 23:43, 8 July 2018 (EDT)

(unindent) I was able to get the original page of that Amazon link with the full comments (reverts after 3 seconds to the linked 'idea page'); see full comments below. There are a few books that I don't see an obvious link, but going from the point of view that was used for other future histories of other authors as well: if it is distant enough future and not obviously in conflict with the rest, it probably belongs. 

------------------- QUOTE

Andre Norton's Forerunner universe, chronological order Elise (profile link is no longer valid)

The list author says: "As humans explore the galaxy, they find the ruins of ancient alien civilizations that have mysteriously vanished. Apparently these "Forerunners" destroyed themselves with high-tech war machines ... and of course, certain humans are eager to salvage whatever they can of this alien technology. Meanwhile, the good guys work to establish a peaceful new civilization. Will it come to the same end as the Forerunners did?

What a fun series this is, old-fashioned science fiction adventures suitable for young readers but definitely for grown-ups, too. (They would probably be rated PG, for occasional violence that is not depicted in a very graphic way, and for a few mild "adult themes.") Some of these stories feature medieval societies and mystical powers that resemble Norton's Witch World series (Moonsinger, Ice Crown, Dread Companion), while others focus more on spaceships and laser guns.

The books can be read in almost any order, since most of them are only loosely related to each other, but I wish I had read them in chronological order. Between the two pivotal wars described in "Warlock" and "Dark Companion," many of the books overlap in time; they are cited here mostly in order of publication. The first one on this list, "Star Guard," contains details that don't quite seem to fit with the rest of the series, and yet it does seem to be part of this same universe."

Star Soldiers

"Contains Star Guard (Central Control limits human exploration of space) and Star Rangers (takes place at the end of the series, as Central Control collapses, same time period as "Dark Piper")"


The Solar Queen

"Contains books #1 and #2 in the very enjoyable Solar Queen series: Sargasso of Space, and Plague Ship. A young man joins the crew of a Free Trader ship that makes cargo runs to planets that few humans have ever seen."


Voodoo Planet

"Solar Queen book #3. Three of the Queen's crew members go on a hunting safari, but a local voodoo priest stalks them through the jungle. This very short novel has also been published in one volume with Star Hunter."


Star Hunter & Voodoo Planet

"Two novels in one volume: Voodoo Planet is Solar Queen book #3. Star Hunter takes place later, same time period as Masks of the Outcasts. Both involve wildlife safaris where the hunters become the hunted."


Postmarked the Stars

"Solar Queen book #4. Making postal deliveries between planets, the Solar Queen is sabotaged. The crew ends up running from the law, alien creatures, and homicidal criminals."


Redline the Stars

"Solar Queen book #5, co-written by P. M. Griffin. The Queen's crew demonstrates bravery and resourcefulness during a horrific disaster in a spaceport."


Derelict for Trade: A Great New Solar Queen Adventure

"Solar Queen book #6, co-written by Sherwood Smith. The crew salvages a derelict spaceship near a spaceport, but uncovers a sinister conspiracy that threatens to destroy them."


A Mind for Trade: A Great New Solar Queen Adventure (A Solar Queen adventure)

"Solar Queen book #7, co-written by Sherwood Smith. While retrieving cargo from a dangerous planet, the crew encounters evil villains and mysterious survivors of a previous expedition."


Eye Of The Monster

"The reptilian natives of Ishkur stage a massacre against humans and Salariki aliens who have set up trading posts on their world. Several survivors flee through the jungle, hoping to reach the last fortified settlement, but murderous Ishkurians are hunting them."


The Game of Stars and Comets

"Scheduled for release early in 2009, this volume will include four short books: Eye of the Monster, The X-Factor, The Sioux Spaceman, and Voorloper."


Warlock

"Contains all three Shann Lantee books. Storm Over Warlock and Ordeal in Otherwhere occur during the Council-Confederation war, which is a turning point in the series. Forerunner Foray takes place a generation later."


Masks of the Outcasts

"Contains Catseye and Night of Masks. Both start in a slum called the Dipple (short for "displaced people") on the planet Korwar soon after the Council-Confederation war."


Star Hunter

"Two characters who don't like each other very well leave the Dipple and end up trekking across an unexplored planet, pursued by bizarre creatures, trying to figure out an alien device that has killed all the humans who have come before. This very short novel has also been published in one volume with Voodoo Planet."


Janus

"Contains Judgement on Janus, and Victory on Janus. An indentured servant leaves the Dipple, escapes on a remote planet, and finds himself aligning with the creepy aliens instead of his fellow humans."


The X Factor

"A misfit son steals a spaceship and travels to the planet Mimir, where he gets mixed up with a Zacathan alien, a guild of criminals, and Forerunner ruins."


Moonsinger

"Contains books #1 and #2 of the excellent Moonsinger series: Moon of Three Rings, and Exiles of the Stars. A spaceman meets a body-swapping alien who helps him learn a lot about the Forerunners."


Flight in Yiktor

"Moonsinger book #3. A deformed alien can't remember how he ended up in the Dipple, a slum on a world that is not his home. Maelen the moonsinger and Krip the spaceman help him flee to the planet Yiktor, but villains pursue them."


Dare to Go A-Hunting

"Moonsinger book #4. Maelen, Krip, and Farree the alien embark on a quest to find Farree's home world. In the process, they learn some surprising things about the Forerunners."


Brother to Shadows

"An assassin becomes bodyguard to a Zacathan alien searching for Forerunner artifacts. Their efforts are undermined by a sort of geisha girl who is also an assassin."


The Zero Stone

"A gem dealer and an intelligent mutant cat try to find the origin of a mysterious stone that has connections to the Forerunners."


Uncharted Stars

"Sequel to "The Zero Stone." Jern Murdock and Eet the mutant feline continue their search for the source of the Zero Stone and discover that it is even more powerful than they realized."


Search for the Star Stones

"Scheduled for release in November 2008, this volume contains both "The Zero Stone" and "Uncharted Stars.""


Forerunner

"On a planet where many races mingle together, a human meets a descendant of the mysterious Forerunners. They travel to an ancient ruined city, where her Forerunner ancestry manifests itself."


Forerunner: The Second Venture

"Sequel to "Forerunner." After Simsa escapes from researchers who want to study her, she finds herself on a world left barren by an ancient war among the Forerunners."


Voorloper


Ice Crown

"Searching for Forerunner artifacts, archeologists land on a world where humans have created a medieval society. One of them befriends a local princess and is swept into dangerous adventures and political intrigue."


The Iron Cage

"On a planet few humans have seen, three human orphans are adopted into a tribe of aliens who are so primitive that they are almost animals. When a spaceship full of humans arrives, the children find themselves torn between the two societies. Although it's not quite clear, this book seems to be discussing the Psychocrats who make an appearance in "Ice Crown" and "Gods and Androids.""


Dark Companion

"Contains Dread Companion (features Forerunner descendants) and Dark Piper (takes place as Central Control is collapsing, same time period as "Star Rangers")"


Gods and Androids

"Contains books #1 and #2 in the Psychocrat miniseries: Android at Arms, and Wraiths of Time. Has a skewed /alternate timeline." END QUOTE -------------------

Hope this helps. SF&F-fan 23:40, 8 July 2018 (EDT)

Thanks! It's a good place to start, but I would be a little hesitant to start creating nested series (i.e. putting series into super-series) without being able to consult a Norton expert who could confirm that nothing got messed up. Back in the 1990s and 2000s I would have asked on Usenet, but Usenet is moribund now. Perhaps Goodreads or Reddit may work. Ahasuerus 11:10, 10 July 2018 (EDT)
Andre Norton Books seems to have things pretty well organized into series. ···日本穣 · 投稿 · Talk to Nihonjoe 13:47, 10 July 2018 (EDT)

Nonfiction in "Eternal Haunted Summer"

Eternal Haunted Summer is a non-genre magazine, whose topic is the practice of paganism. Most, but not all of its fiction & poetry is either speculative or on mythic themes, and the magazine has been indexed in this DB since 2016 due to poetry having been Rhysling-nominated. My question is about the nonfiction, none of which is genre-related except for some of the reviews, and some interviews of spec fic writers. Question 1: In general, should non-genre nonfiction in this type of publication be included in the database? Question 2: Given that the nonfiction in Eternal Haunted Summer already has been added, should it be removed? --Vasha (cazadora de tildes) 00:30, 9 July 2018 (EDT)

If we classify this magazine as non-genre, then no non-fiction from it is eligible (regardless if it is a review of Lord of the Rings or an article from Asimov). I do not see the non-genre flag on it though so I wonder if whoever is entering these issues thinks that the magazine is genre for some reason (which would change the rules for the non-fiction). We probably should find the editor(s) adding the issues and invite them to the discussion if they do not chime in. Annie 12:52, 9 July 2018 (EDT)
Vasha, do you speak of removing the non-genre essays or all of them? I do advocate the inclusion of genre essays (that is, essays & reviews on speculative fiction), if an issue of a magazine is included in the database: it may be interesting to some of us. Stonecreek 14:24, 9 July 2018 (EDT)
I think there is an explicit policy against including nonfiction in nongenre magazines, although I don't see it in the ROA--can you quote it, Annie? Be that as it may, the case of EHS highlights something that we overlooked when revising the inclusion policy for webzines: we didn't change the wording of the exception for award-nominated publications. It still says "Online publications available exclusively as a Web page, but only if shortlisted for a major award." Besides needing to be updated to something like "Online publications not otherwise eligible if shortlisted..." this wording doesn't make it clear that we've decided that having a content item nominated makes the publication eligible, not just the whole magazine having been shortlisted. And, going back to the problem at hand, the question of whether we do or don't include a nongenre magazine with award-nominated contents is separate from the question of what we do with its nonfiction. --Vasha (cazadora de tildes) 15:44, 9 July 2018 (EDT)
It is not in the ROA - it was somewhere else in the help pages I think (or maybe in an old discussion somewhere from way back when?). I will see if I can track it down. We had this discussion awhile back. I still think the same - mainly because if we include them from one publication, it does open the door for all reviews and articles about sf in all mainstream media - and we are mainly a fiction DB after all... It sounds great on paper but we need to consider consistency as well. Maybe we should start a new discussion in "Rules and Standards" about what we include from non-genre magazines/books? Annie 17:02, 9 July 2018 (EDT)
Found it. The two relevant sections:
  • Sometimes, a non-genre magazine will devote an entire issue to speculative fiction and/or articles about it. This can be regarded as a genre publication and genre non-fiction should be cataloged along with the fiction (even though we do not normally catalog non-fiction from non-genre magazines).
  • Interior art specifically associated with a speculative fiction story may be entered, if the data is available. Otherwise do not enter any interior art. Normally no editorials, letters, or essays will be entered. Reviews of SF works may be entered, but this will be rare. Significant essays specifically connected with SF works may optionally be entered, but this also will be rare.
We are not in the first case (this is not a special issue of the magazine/webzine). Unless someone wants to make the case that we should enter more content from online publications than we do from a non-online ones, I'd say that this applies here. The door IS open if there is speculative fiction so technically the SF-related ones can stay (and I won't kill them if I am moderating this) but I do not think that just any essay/review should be added... Annie 17:17, 9 July 2018 (EDT)
That second section leaves it open to the editor's choice whether to add reviews & articles about spec fic. That figures; if we can't reach consensus (we had Stonecreek & Annie expressing opposite opinions today) then it's open... It's worded in such a way as to urge people to be cautious, though. Only include nonfic if you really think it's relevant. When in doubt, leave it out. --Vasha (cazadora de tildes) 17:40, 9 July 2018 (EDT)
To some extent. There is that word "significant" over there that kind of points to the fact that we really do not want all the essays. I don't disagree with Christian that this information will be interesting to some people (if anything, I much rather prefer to add a complete magazine than just pieces of it) but we come own to what the DB is - the reason we allow the non-genre books and magazines at all is because they decided to print one of our stories. Otherwise, I'd love to have all the SF related reviews and essays from LRB, NYRB, NYRTB, TLS and so on indexed but that's not really the focus of the DB. :) Annie 18:26, 9 July 2018 (EDT)
Well, whether or not we include reviews of genre fiction and suchlike when we index a nongenre publication, we definitely do not want completely irrelevant contents, right? There is nothing in the "award exception" that says, when something in the magazine has been nominated for an award, include the whole magazine including articles that have nothing to do with spec fic.... --Vasha (cazadora de tildes) 18:50, 9 July 2018 (EDT)
Unless it is considered a genre magazine altogether (which the lack of the "non-gnre" flag makes me wonder about). We catalog everything in OUR magazines. Thus my proposal to try to find who entered them and work with them before any action is taken - or at least give this thread a few days so people can see it. :) Annie 18:55, 9 July 2018 (EDT)
Let me see if I can find the submissions which added non-fiction titles to Eternal Haunted Summer. Ahasuerus 19:33, 9 July 2018 (EDT)
No need. I have entered several issues of the magazine, perhaps all of them, and as I recall it was because of nominations for the Rhysling awards. Firstly, I don't know that I would consider this to be a non-genre magazine and I certainly didn't enter it as one. The issues seem to be predominantly poetry and fiction and many of the reviews are of genre works. Thus I entered them as regular magazines as opposed to non-genre ones (i.e. actual editor rather than "Editors of Eternal Haunted Summer"). I will note that the magazine having a dual focus on fiction and paganism doesn't worry me any more than Analog having a dual focus on SF and science. At the time I entered these I only entered issues that had nominated poems. The way I read the exception for genre award nominations was that it qualified the entire issue, not just those items that were nominated. Whether that was a correct interpretation is somewhat moot given the recently expanded scope. That leave only the argument as to whether this webzine is genre or not. I lean towards inclusion in edge cases and would continue to argue that this is an eligible webzine on its own merits. --Ron ~ RtraceTalk 19:40, 9 July 2018 (EDT)

(unindent) Thanks, Ron. I have only looked at one issue in detail (Summer Solstice 2017) but I have also read other issues in part, and I would like to disagree slightly. The subtitle of the magazine is "Pagan Songs and Tales;" and that strikes me as a very apt description. The poems included in the SS17 issue are largely of a devotional nature: they retell myths for the purpose of elucidating their spiritual meaning. "The Popaeg Dirge," "For Agni," "The Breaking of the Waters," "Quetzalcoatl in a Cowboy Hat," "Geomystica," etc... As for the fiction, three are speculative (one a myth-retelling, two depictions of religious rites in which literal miracles occur); the fourth, "Languid Guidance," is a non-genre depiction of a modern pagan gathering. Then there is the essay "Eight Minutes to Reach the Sun?" which is entirely concerned with spiritual guidance. The other nonfiction: First, four interviews (an astrologer, a songwriter, a poet, a pagan spiritual leader); none of those people are in our database from any other publication except EHS. Then, reviews: three nonfiction works about paganism, two collections of poetry, and three novels (all three speculative). As you can see, religion is a common element in every single item in this magazine; speculative fiction is not. Depending on how you categorize the poetry, only a minority of the magazine may have to do with spec fic. --Vasha (cazadora de tildes) 20:03, 9 July 2018 (EDT)

Internationalization of softcover formats ("pb" and "tp")

I'm trying to give the still unresolved "softcover problem", which has been discussed several times so far, another shot. As requested on my my talk page, I created a separate page which describes the problem, gives a detailed example and contains all possible solutions and non-solutions which have come up in several threads about this issue so far. Which means I also included the "counterproductive" ones in order to get a full picture. I hope I didn't miss something.

Here's the page: Softcover publication formats on international markets

My idea is to collect questions, remarks and ideas about the problem which are described there here, improve that page based on the answers, and hopefully and eventually the page will become the bases for a vote on the R&D page.

Jens Hitspacebar 12:45, 9 July 2018 (EDT)

Thanks for posting this one, Jens! I think that we have another option as well (a modification of your option 1 with a more palatable alternative) - leave tp/pb in place (so we do not destroy all the information that had been collected so far) but add a third one: "softcover" (sc) for the books where we do not know the size or where the tp/pb distinction does not really matter. This way Bulgarian and Russian books can be just sc (and the 16 or so possible formats are noted in the notes); same for the UK A/B/C formats. That way sc will be the defacto standard for non-US books; US books will still be split into UK/US. It is inconsistent but this started as a US DB after all - and destroying the data just makes no sense. Alternatively (as you already mentioned), we can delete the old pb/tp AND add a new field for sizing (which is populated with mmpb/tp for the books that now are marked as such). But that will mean changing all kinds of lists to actually show the new sizing field together with the format (so where is says pb now, it would say sc (mmpb).
I am against having separate country-based formats (they won't be language based but country based - because a Bulgarian language book printed in Germany will use the German formats) and it will get extremely complicated to actually figure out what a possible format is for a book. And the list of formats will get unmanageable long (and confusing). Annie 13:35, 9 July 2018 (EDT)
I don't see a difference in your proposal regarding a new "sc" format compared to the first solution ("1. Add a new "softcover" format and keep "pb" and "tp"") presented on that page. Jens Hitspacebar 14:26, 9 July 2018 (EDT)
Maybe the numbering scheme I initially used ("1a" and "1b") was confusing. I changed it to a simple "1" to "6". Jens Hitspacebar 14:35, 9 July 2018 (EDT)
It sounds very reasonable, Jens! We would finally get rid of those endless discussions & misunderstandings, if we just add 'softcover' to the list of possibilities. The one remaining question is: can we migrate the existing publications to the new standard? Christian Stonecreek 14:36, 9 July 2018 (EDT)
I added more flesh to the existing text about migrating to "sc" on the page. Look for "Affected existing non-English publication" there. Jens Hitspacebar 15:15, 9 July 2018 (EDT)
I could have sworn that the "keep the pb/tp and add sc" was not there this morning (but I was reading from my phone so might have just scrolled badly). :) My bad. Annie 16:46, 9 July 2018 (EDT)

Background

One thing to keep in mind is that "pb" and "tp" as defined by the ISFDB data entry standards do not match the industry-standard US definition either. In the US, the distinction between "trade paperbacks" and "mass market paperbacks" is as follows.

  • "Trade paperback". If a book fails to sell during a certain period of time, it is returned to the distributor/publisher. The vast majority of "trade" paperbacks are larger in size ("tp" in ISFDB terms), but it doesn't have to be that way. Some "small size" paperbacks ("pb" in ISFDB terms) published by certain specialty publishers are technically "trade" paperbacks; they are supposed to be returned to the publisher if they do not sell. Some of them carry a special warning on the copyright page to prevent bookstore employees from treating them as regular mass market paperbacks.
  • "Mass market paperback". If a book fails to sell during a certain period of time, its cover is stripped. The rest of the book is then pulped while the stripped cover is returned to the publisher as proof that the book has been destroyed. (You may occasionally find stolen cover-less mass market paperbacks sold at flea markets.) Most "strippable" paperbacks are "pb" size, but some are larger than what we define as the "pb" format.

Back when the project started, Al and I were only dimly aware of the differences between trade paperbacks and mass market paperbacks. Later on, when the distinction was made clear to us, we decided to continue using the terms "pb" and "tp" to capture book sizes instead of the way they are used by bookstores and publishers.

What this means is that our "pb" and "tp" are uniquely ISFDB designations which do not map neatly onto current publishing practices in the US or anywhere else. And I should probably copy this explanation to Jen's page so that I wouldn't have to type it again in the future :-) Ahasuerus 15:21, 9 July 2018 (EDT)

I wasn't aware of that. Yes, please add this information to the page. Jens Hitspacebar 15:37, 9 July 2018 (EDT)
Done! Ahasuerus 15:56, 9 July 2018 (EDT)

Invisible characters nixed

The data entry filter which is applied to all ISFDB submissions has been modified to filter out a number of "invisible" characters and they have been removed from the database. "Invisible" characters are typically added to submissions when editors copy-and-paste notes from other Web sites (OCLC is a known offender), so their removal should not impact what we do. If anything looks odd, please post your findings here. Ahasuerus 16:16, 10 July 2018 (EDT)

Publication pages: Cover art changes

As per the outcome of this discussion, the way cover art titles appear on Publication pages has been changed to match the way other variants are displayed. Some examples:

Ahasuerus 18:11, 10 July 2018 (EDT)

I like this change. :) ···日本穣 · 投稿 · Talk to Nihonjoe 19:30, 10 July 2018 (EDT)
In retrospect it was the obvious thing to do. Then again, most things are obvious in retrospect :-) Ahasuerus 20:46, 10 July 2018 (EDT)

E-mail validation added

"Edit Author" has been modified to perform basic validation of email addresses. The validation logic is not very thorough, but it should prevent editors from accidentally entering Web page URLs into the "Email Address" field. Ahasuerus 20:45, 10 July 2018 (EDT)

Display of VTs on parent title pages

This Help Desk discussion of the way we display VTs on their parent titles' pages is still ongoing. As an experiment, I tweaked the software to display VTs' Notes as mouseover bubbles where available -- see the "Year" column of the "Translations" table on this title page for an example.

Admittedly, it's a quick and dirty solution, in part because I know of no way to make mouseover text display embedded HTML (tables, lists, etc) correctly, but it was easy to implement. If it looks like an improvement, we can keep it. If not, I will revert the change. Ahasuerus 21:53, 11 July 2018 (EDT)

I like it - as much as it may look ugly for longer notes, it is serviceable (and until we end up moving the translators in their own field, there is probably no better way anyway). I did not even think about the mouseovers. Annie 00:19, 12 July 2018 (EDT)
One small thing. Look at this one. All of the 1 line entries are now 2-lines ones. Any chance the year column can be made slightly wider? Annie 01:15, 12 July 2018 (EDT)
Fixed! Ahasuerus 11:40, 12 July 2018 (EDT)
Nice addition. As for "make mouseover text display embedded HTML": it's possible using pure CSS. See "CSS Tooltip" at w3schools.com. Instead of putting the text you want to display in the "title" attribute of a SPAN, you have to put it inside a DIV, which will be hidden when the page is rendered and only becomes visible on mouseover ("hover"). Jens Hitspacebar 04:46, 12 July 2018 (EDT)
Thanks, I'll take a look. Ahasuerus 10:40, 12 July 2018 (EDT)
Can something else than a question mark be used? I don't know, maybe it's the space between the number and question mark that makes it stand out more than those used for transliterations, formats, etc. To me though, it looks like we're questioning if the date is correct. Given this is more use for an experienced editor, perhaps don't use a symbol at all and just put the mouse overs on the years? -- JLaTondre (talk) 07:18, 12 July 2018 (EDT)
Good point. A better alternative may be one the following "plus" characters, which are often used to indicate that there is more content: ⊞ or ⊕ Jens Hitspacebar 07:41, 12 July 2018 (EDT)
This is very useful. I may still put the full set (duplication) with explanations and directions in the main title note after a BREAK or a separate wiki page to assist first time viewers, which means I would like to format the information, but any table layout would not be in the individual translated titles and hence not in the mouseover. I'd also prefer a different symbol, but offer ⌕ and ⓘ. Although how these look as superscripts may eliminate them - I have enough trouble telling it's a question mark and not a 7. ../ Doug H 09:20, 12 July 2018 (EDT)
Good points. I have changed them to ⓘ for now. Let's see if it works for everybody. Ahasuerus 11:40, 12 July 2018 (EDT)

HTML now allowed in mouseover bubbles

I ended up using Jens's idea to allow HTML in mouseover bubbles. See the 1982 German translation of Heinlein's "Life-Line" for an example of how it works. The software changes needed to support this functionality were fairly significant, so if anything looks off, please let me know. Also, you will need to force a full page reload (Control-F5 in most browsers) for the new bubbles to take effect. Ahasuerus 19:04, 12 July 2018 (EDT)

I like. Both the bubbles & the symbol. Thanks. -- JLaTondre (talk) 21:11, 12 July 2018 (EDT)
There is also the nice side effect that the new code works on my mobile phone browser (Firefox for Android) where the old one didn't. --Vasha (cazadora de tildes) 21:39, 12 July 2018 (EDT)
Thanks, looks good. However, the readability (contrast) is not the best with white font on grey background. I suggest to change the font color to black, the background color to white and add a black border to the CSS class:
.tooltip .tooltiptext {
    visibility: hidden;
    width: 150px;
    background-color: black;
    color: white;
    text-align: left;
    padding: 5px 0;
    padding-left: 3px;
    border-radius: 6px;
    border: 1px solid black;
 
    /* Position the tooltip text */
    position: absolute;
    z-index: 1;
}
Jens Hitspacebar 06:50, 13 July 2018 (EDT)
The bubble's width also could be bigger. This record is an example with a long note in the variant title and therefore a big mouseover bubble. Maybe increase to 300px or 400px width? Jens Hitspacebar 07:05, 13 July 2018 (EDT)
I think it would be more intuitive for the mouseover bubble to activate over the language column, rather than the year.--Rkihara 12:44, 13 July 2018 (EDT)
Granted, it would make more sense for translations, but the bubble is also displayed for regular VTs which do not have the language column. If we want to stay consistent across tables, our choices are the year column and the title/pseudonym column. The title column would be problematic because it would potentially have 2 mouseover bubbles: one for transliterations and one for VT notes. Which leaves the year column as the only solution that I could think of :-\ Ahasuerus 13:20, 13 July 2018 (EDT)

Display Tweaks -- 2018-07-13

I have tweaked the bubbles to be in line with what Jens suggested. You'll need to force a full page reload (Control-F5 in most browsers) to see the changes.

The only thing that I didn't implement was the proposed increase from 150px to 300-400px. I have the following concerns:

  • Would it cause problems for mobile users who have limited real estate?
  • It would result in mostly empty bubbles for short transliterations

I guess the second issue could be addressed by having two types of bubbles: smaller ones for transliterations and longer ones for VT notes. I don't know how much of an issue 300-400px would be for mobile users, so I'll wait for their feedback. Ahasuerus 14:18, 13 July 2018 (EDT)

Those things are un-clickable on IOS anyway (on the IPhone at least) - the transliterations ones don't work either (I think I mentioned it when we moved to the new way to show transliterations and we never resolved it). But as a whole making a popup so large that you need to scroll so you can close it is always a bad idea. I like it as it is now - if someone sees something interesting they want to look into, they can always just open the title. Annie 14:30, 13 July 2018 (EDT)
Ahasuerus, you have forgotten to change "color" to "black" and "background-color" to "white" :) It now has white text on black background, which makes links in notes almost unreadable, see example. Jens Hitspacebar 15:28, 13 July 2018 (EDT)
Oops, I just realized that I didn't post the correct CSS above. It doesn't match the text of my suggestion there. The CSS should be "color: black" and "background-color: white". Can you change it, please? Jens Hitspacebar 15:56, 13 July 2018 (EDT)
Done! I have also changed the width value. "Question mark" bubbles remain at 150 pixels while "informational" bubbles have been expanded to 300 pixels. Let's see how well it works. (And yes, you'll need to hit Control-F5 again to see the latest formatting.) Ahasuerus 16:54, 13 July 2018 (EDT)
I think this width is OK. I do have to zoom out my mobile phone screen a little more than I usually would in order to fit the bubble on the screen, but it doesn't make the text too small to read; and this is a good compromise between being readable in mobile and being ridiculously long and narrow in other browsers. --Vasha (cazadora de tildes) 17:19, 13 July 2018 (EDT)
Thanks, folks. I guess we can declare victory for now and see if anything else comes up. Ahasuerus 20:15, 13 July 2018 (EDT)
When I mouseover the title in the list of publications when the publication title has a transliteration, I can't see any of the title because the popup covers the entire thing instead of floating to the right of it a little. You can see an example here for this record. Can we tweak the placement of the popup so it looks more like this? I'm using Firefox 61.0.1 on Windows 7 Enterprise Service Pack 1. It also happens in the most recent Firefox version for macOS X (I'm not at home, so I can't tell you the details). It looks fine in Chrome 68.0.3440.84 (Official Build) (64-bit). ···日本穣 · 投稿 · Talk to Nihonjoe 19:35, 31 July 2018 (EDT)
Do you have any weird plugins or something else weird happening in your FF (magnification?)? Because on the same version, same OS, the popup is showing up on the right as expected for me. Annie 19:43, 31 July 2018 (EDT)
Nope. ···日本穣 · 投稿 · Talk to Nihonjoe 20:02, 31 July 2018 (EDT)
Let's see... I am able to recreate the problem using Firefox 61 under certain resolutions. It's not consistent; sometimes Control-F5 changes where the bubble appears. It looks like a Firefox bug/inconsistency. Let me see if I can force the bubbles to appear to the right of whatever it is they are associated with. Ahasuerus 20:18, 31 July 2018 (EDT)

Nepali and Pashto/Pushto added to the list of supported languages

Nepali and Pashto/Pushto have been added to the list of supported languages. Ahasuerus 16:09, 12 July 2018 (EDT)

Tables: what do we need?

There have been various discussions of using tables in notes lately. A few hundred publications currently have simple tables in notes used for putting lists into parallel columns and things like that (example 1, example 2). There are also tables like this that have borders between cells to make them more readable. We are about to transition to using BBCodes instead of HTML, which means that there won't be any attributes available, not even the option to choose whether to have borders or not, as well as things like centering text or left or right alignment, etc.

Ahasuerus has said that he could create some custom BBCodes which would allow some options beyond just one way to make a table. Question for anyone here who has used tables or might: what options do you think would be really necessary?

Personally I think we could do with just having two versions of tables, one with borders and one without; I think it's the only thing that would make a major difference to readability, and having no control over alignment, column width, etc. would just make the tables a bit less pretty. Rowspan/colspan is helpful but rarely used. --Vasha (cazadora de tildes) 16:18, 12 July 2018 (EDT)

I think, you need only a table with borders, this is more readable.--Wolfram.winkler 02:25, 16 July 2018 (EDT)

Fixer: defining the manual submission process

As many of you know, we have been using a data acquisition robot, User:Fixer, to keep up with new US/UK (and some Canadian) releases since late 2008. Fixer finds new books, cleans up the data (regularizes publisher names etc), prioritizes major publishers, creates submissions and so on.

The current process, which is described here, works reasonably well, but it's increasingly labor-intensive, which has become an issue.

Description of the Problem

Volume

There are two fundamental problems. The first one is that there are a lot more new books getting published these days than we ever expected. Every month Fixer finds up to 10,000+ new ISBNs and up to 20,000+ new ISBN-less ASINs. I have been slowly beefing up Fixer's semi-automated processes which assign priorities to new ISBNs, but there is only so much that can be done without human intervention. Over time, I have been spending more and more of my time on organizing and massaging Fixer's monthly haul.

Data Quality

The second problem is that Fixer's submissions are not as clean as human-created submissions. There is a special Help page, Help:How to work with Records Built by Robots, which describes all kinds of things which can go wrong with robot-generated submissions. This means that moderators have to spend additional time and effort when processing Fixer's submissions. Because they compete with human-generated submissions for moderators' limited time, they tend to sit in the queue longer. In addition, unless a moderator has been working on Fixer's submissions for a long time, he or she has a good chance of missing invalid or incomplete data.

For these reasons, I have been adding most Fixer-identified ISBNs personally, which is very time-consuming and affects my development work.

Original Solution

Originally we planned to enhance the current ISFDB submission process to address this issue. The idea was that Fixer would continue creating regular submissions, but they would be added to a special "robots only" submission queue instead of the standard "New Submissions" queue. These "special" submissions would be later massaged by editors and converted to regular submissions which would then be approved by moderators. It was a nifty idea, but, unfortunately, it would require a great deal of work to implement.

New Solution

A few months ago Annie and I began working on a less ambitious approach which wouldn't be as nifty but could be implemented much faster. The basic idea was that we would have Fixer build Wiki pages with basic information about each Fixer-identified ISBN. These Wiki pages would then be used by human editors to create regular submissions following User:Fixer/Public/Instructions. It should result in higher quality submissions, which should in turn make it possible for moderators to approve them quickly. Annie's testing seems to suggest that the approach should be viable.

At this point we have three types of Fixer-maintained Wiki pages:

but we can always add more types. For example, if everything works as well as we hope it will, we can start leveraging Fixer's data from other sources, notably OCLC, including non-English ISBNs, but that's Phase 2.

For now, the editors who are interested in working on adding Fixer-identified ISBNs to the database are encouraged to review User:Fixer/Public, User:Fixer/Public/Instructions and Help:How to work with Records Built by Robots. Does the process look viable? Anything that you would like to see changed or added? Ahasuerus 18:22, 16 July 2018 (EDT)

Amazon removing books by some SF authors

FYI, Amazon has removed the majority of books by certain indie SF authors like J. A. Cipriano and Michael-Scott Earle. Apparently it has something to do with the ongoing controversy surrounding Amazon's Kindle Unlimited program, but the important thing is that it emphasizes that Amazon's data is not permanent and is subject to change at any time. Ahasuerus 18:39, 17 July 2018 (EDT)

They are a seller - they may be the biggest and meanest of them all but they are not a bibliography, they are a seller. At least they seem to still be hosting the covers (that was my first thought when I saw the dust up with Cipriano a few days ago)... Annie 19:54, 17 July 2018 (EDT)
Yes, they never seem to delete or change addresses of cover images, even when the books have long vanished or they've changed the image displayed on the book's page. Damned good thing too, since we don't have the storage space they do. --Vasha (cazadora de tildes) 20:31, 17 July 2018 (EDT)
At the moment we host 141,240 covers and link to 269,746 Amazon covers. We do have enough space to host everything that we link to, although I would have to change our backup process to be more efficient. The big problem would be the amount of time and effort that it would take to upload and link 269,747 cover scans. Ahasuerus 21:04, 17 July 2018 (EDT)
Being as images aren't our main priority, would it really be a disaster if they disappeared sometime? --Vasha (cazadora de tildes) 20:31, 17 July 2018 (EDT)
Sometimes a cover change is all that differentiates editions - so yes, they are important in some cases. Plus we care about the artists - not having the images makes it very hard to get their works properly varianted and/or merged especially when one is looking at an interior art or a reprinted cover :) Annie 20:41, 17 July 2018 (EDT)
Their policy seems to have changed over the last few years. It used to be that they almost never deleted ISBNs even if they were cancelled prior to publication. This was usually bad for publishers and authors, but sometimes good for bibliographers.
A few years ago the policy apparently changed; their ISBNs disappear much more frequently now. Amazon is still a good resource, but I tend to be more cautious when working with their data these days. Ahasuerus 21:00, 17 July 2018 (EDT)
This can be especially true for print-on-demand and e-books. I've bought books with one cover, then a new edition comes out and the cover changes, or the e-book will have a completely different cover. Publishers can be very nonchalant about their publishing practices. MLB 03:37, 18 July 2018 (EDT)

(unindent) Cipriano's and Earle's bibliographies have been updated with a little help from Fixer's internal database. Ahasuerus 20:23, 19 July 2018 (EDT)

YouTube Narrations.

I've entered a number of these to this site under the story's "webpage" field, but it seems to be a possibly fruitless, and anonymous listing, especially since several stories have multiple narrations. Would it be possible to create a whole new field for these youtube narrations? My favorite narrators being people like Morgan Scorpion and Ian Gordon (HorrorBabble). It could be something simple, like the story's name, author, narrator, story's length, and website. It would be so much easier to find these narrations that way otherwise they may be lost on this site. We list webzines and PDH files, why not these? Some of these may never be transferred to something more solid like Audible or CDs. Maybe it's me, but I grew up listening to these narrations (I'm sixty, so they are nothing new), and recorded books seem to becoming more popular, so why not. Just tossing this out there for discussion. Maybe I'm posting this on the wrong forum. Lemme know if I've wandered off on the wrong track. MLB 03:33, 18 July 2018 (EDT)

Are these for older books? If so, we may want to treat them as audiobooks. ···日本穣 · 投稿 · Talk to Nihonjoe 11:48, 18 July 2018 (EDT)
Are those downloadable? If they are, it will fit under "digital audio download" just fine - together with all podcasts and what's not that read you a story. If they are not, we have yet another iteration of the "web only story" kind of thing.
Technically narrators and lengths go into the Notes fields these days (same way Translators do)... Annie 12:21, 18 July 2018 (EDT)
Well, if it's on YouTube, it can be downloaded using any number of downloaders like youtube-dl. However, that's third party processing, which may not count as "digital audio download". In addition, YouTube's Terms of Service say:
  • You shall not download any Content unless you see a “download” or similar link displayed by YouTube on the Service for that Content
So I guess the answer depends on whether:
  • these public domain narrations are available for download elsewhere, e.g. on LibriVox
  • if not, then whether YouTube makes them downloadable
Ahasuerus 12:40, 18 July 2018 (EDT)
I believe you can only download your own videos from YouTube[1]. As for youtube-dl and the ilk, I can save a web page to my computer using my browser. I don't think we want to go down that route as then everything is downloadable. External links seems the best case for this for now. -- JLaTondre (talk) 18:26, 18 July 2018 (EDT)

Magazines and fanzines can now be cloned

As per FR 745, the software has been modified to allow cloning magazines and fanzines. Ahasuerus 19:43, 18 July 2018 (EDT)

Publication page - magazine issues

Back in March we changed all publication pages to display container titles at the top of the Contents section -- see FR 1127 for details. What we didn't realize at the time was that it resulted in link duplication for magazine/fanzine issues.

Consider Apex Magazine, June 2009. The container line says:

which is as it should be. However, the same link, http://www.isfdb.org/cgi-bin/pe.cgi?25232 , is also displayed at the top of the page where it is called "(View All Issues)".

My thinking is that we could get rid of "(View All Issues)" and move "(View Issue Grid)" to the "Editor Title" line as follows:

What do you think? Ahasuerus 19:57, 18 July 2018 (EDT)

Even though it is the same link, it is a different label and it serves different purposes in my mind. Removing "View All Issues" will make it very hard for someone that does not understand how our magazines work to find how to find all the issues (it may not dawn on them that they need to click the thing in the square brackets to find all of the issues). So I would prefer to keep both in place - despite the duplication. Annie 20:11, 18 July 2018 (EDT)
Agreed; the Editor Title line is a list of information about the magazine, so don't mix it up with view options, a different thing. --Vasha (cazadora de tildes) 20:14, 18 July 2018 (EDT)
In that case, how about we insert a new line, "Related Issues", between "Publication" and "Editor", and move "(View All Issues)" and "(View Issue Grid)" to it? Ahasuerus 09:29, 19 July 2018 (EDT)
That line shouldn't be between "Publication" and "Editor" (it's true that that would keep it where it was before, but the location nonetheless makes no sense); instead, it should be between "Format" and "Notes." --Vasha (cazadora de tildes) 14:01, 19 July 2018 (EDT)
Why are we trying to move it at all? It makes sense where it is (the same way Edit makes sense on the upper right corner even though it is also on the left menu)... Annie 14:09, 19 July 2018 (EDT)
The main problem that I have encountered is wrapping. Depending on the size of your monitor and the resolution that you use, it can force wrapping, e.g. Analog Science Fiction/Science Fact, June 1971 wraps on a 27" monitor at 150%. Ahasuerus 14:31, 19 July 2018 (EDT)
So it will solve the problem for people with narrow screens but will cause an issue for ones with short ones (I like the link being there as soon as I open a magazine and without the need to scroll down. How about playing with the space that is now occupied by "Publication Record # 57137"? This is the real problem in the real estate in that line in my opinion, not the two links. I know that it wraps in two columns and I can see what the problem on a smaller screen but I still do not think that we should move them away. Annie 15:02, 19 July 2018 (EDT)
I do like having the publication number where it is. Ahasuerus is right that four item mms on a line is a lot. How about this: put the View All Issues on the right under the pub number and edit link. That way, both action items on the right out of the column of info about the issue. --Vasha (cazadora de tildes) 18:01, 19 July 2018 (EDT)
As for using related - does related mean same editor, same stories, similar topic, same month? I know what you mean, I am not sure a visitor would. Annie 14:09, 19 July 2018 (EDT)
Perhaps "Other Issues"? Ahasuerus 14:33, 19 July 2018 (EDT)
Better than related. :) Annie 15:02, 19 July 2018 (EDT)

(unindent) Here is where I think we are at the moment:

  1. Keep "(View All Issues)" and "(View Issue Grid)" in the metadata (top) section of the page
  2. Possibly reorganize the first two lines to make things more readable

After sleeping on it, I think I like Vasha's proposal: "put the View All Issues on the right under the pub number and edit link". It would move all magazine links to the "Editor" line, which is also magazine-related. Ahasuerus 11:14, 22 July 2018 (EDT)

Magazines with multiple formats

A lot of our magazines have multiple formats these days (ebook and printed for example or even ebook, web and printed for some). Our current solution is to either keep the EDITOR records in one series (which makes the grid look weird) or separate series (which makes it nearly impossible to figure out what issues we have, where they are and if we miss any - or for someone searching a record to understand why the print and digital issue of Clarksworld are not connected anywhere for example). One possible option to solve these problem is to change the Grid page a bit to show the format (when there are multiple formats) thus allowing us to have both the ebook and the printed versions under the same editor record. That will also clean the editor's pages (see Neil Clarke for an example) - I had been reluctant to add the Asimov's, Interzone's and Analog's ebook editions because of that even though I've been getting some of them for years. Anyone has any better ideas? Annie 20:03, 18 July 2018 (EDT)

I like this idea. ···日本穣 · 投稿 · Talk to Nihonjoe 20:09, 18 July 2018 (EDT)
It would be easy to append the format to each issue. However, first we need to decide whether we want to display the format for each displayed issues. Here are the options that I can think of:
  1. Display the format of each issue, e.g. "November [pulp]" or "April 24 [webzine]".
  2. Display the formats only if there are multiple formats anywhere in the grid. For example, it would mean displaying all formats in the Astounding (1937-1971) grid because its format changed from pulp to digest to bedsheet and then back to digest between 1943 and 1966.
  3. Display the formats only if there are multiple formats within a cell. No formats would be displayed for Astounding because there is only one issue per cell. On the other hand, the "August" and "September" cells of the 2014 row in the Fantastic Stories of the Imagination grid would display "[tp]" and "[ebook]" next to each issue.
  4. (Obsolete: When the question originally came up on my Talk page, I suggested that it may be viable to differentiate between paper and non-paper formats, but I no longer think so because we can also have multiple paper and/or multiple non-paper formats per issue.)
My current thinking is that #3 may be our best bet, but I'll have to think about it some more. Ahasuerus 10:03, 19 July 2018 (EDT)
I am more in favor of 2 (or even 1). 3 will leave a very inconsistent display and will make it even harder for an editor to figure out what we have (is that single issue the ebook or the paper one? did this magazine changed format (we have the data, why not make it easy to find)? and so on). Plus this allow us to clean some long-lingering format issues (when you can see them in a table, it is so much easier to spot that there is a switch and go investigate and fix it).
We can always add a user preference or a toggle to show/hide those from magazines that never changed formats (or from issues that we have in single format only). Annie 13:20, 19 July 2018 (EDT)
FR 1172 has been created to document this discussion. I'll probably implement option 2 first, which should let us gauge how busy the grids will be when they include formats. Ahasuerus 11:03, 22 July 2018 (EDT)

Series transliterations

It seems like just about everything else has transliterations implemented. Is there a timeline for when series will have this feature? ···日本穣 · 投稿 · Talk to Nihonjoe 20:10, 18 July 2018 (EDT)

I'd support such a change - I won't admit how often I start transliterating one of those and then realize that the field is actually for a parent, not for transliteration :)! Annie 20:14, 18 July 2018 (EDT)
I have been thinking about this issue for some time. The problem with series names is that they frequently include translations, e.g.:
Suppose we were to create a "Transliterated Series Name" multifield. What would we put there for these 3 series?
The only way I can think of addressing this issue would be to move all English (and other) translations to the Notes field. Which, now that I am thinking about it, may work reasonably well and would be consistent with the way we handle other fields. Ahasuerus 21:46, 18 July 2018 (EDT)
I do not see a problem. Transliterate the non-Latin text, leave the Latin one as is. So for the "Понедельник начинается в субботу / Monday Begins on Saturday", I will put "Ponedel'nik nachinaetsya v subbotu / Monday Begins on Saturday" the same way we do it for all other mixed alphabets elements. It is a transliteration - Latin letters, numbers, dots, commas and so on do not get changed; non-Latin characters get transliterated. Annie 21:58, 18 July 2018 (EDT)
PS: Moving the translations out sounds like a good idea until you see an English book with all the stories in series with strange letters - I don't mind but... I have a feeling this is not what we want. We seem to have a conversation that ties with this over in R&S :) Annie 22:04, 18 July 2018 (EDT)
Let me make sure that I understand correctly. Your concern is that moving English translations from the series name field to the notes field would make the Contents section of publication pages harder to interpret. What currently reads:
  • The Dream of the Lion King • [Re:ゼロから始める異世界生活Ex (Re: Zero Ex) • 1] • novel by 長月達平? (trans. of 獅子王の見た夢? 2015) [as by Tappei Nagatsuki]
would become:
  • The Dream of the Lion King • [Re:ゼロから始める異世界生活Ex • 1] • novel by 長月達平 (trans. of 獅子王の見た夢 2015) [as by Tappei Nagatsuki]
which would be more difficult to process, right? Ahasuerus 12:03, 19 July 2018 (EDT)
Yes. And will also require an English editor to somehow know how to find the series that has no English words into it so they can add it to their book. In a perfect world, this display will be able to show the series in the title language
  • The Dream of the Lion King • [Re: Zero Ex • 1] • novel by 長月達平 (trans. of 獅子王の見た夢 2015) [as by Tappei Nagatsuki]
and
  • 獅子王の見た夢 • [Re:ゼロから始める異世界生活Ex • 1] • novel by 長月達平
but we are nowhere near this at the moment. If we decide to pull the translations from the names, I am fine with that but it is not a requirement for having transliterations added. :) Annie 13:13, 19 July 2018 (EDT)
True, it's not a requirement. However, it's been my experience that it helps to have a general idea of where we are going before we start changing the software. There have been times when I had to undo things that I had thoughtlessly put in earlier and it was no fun.
In this particular case there have been multiple related user requests -- e.g. see FR 807 "Allow to enter a German series title in database" or FR 406 "Allow multi-series titles" -- but we don't have a solid set of requirements, much less a comprehensive design. We use the "series name" field as a catch-all field for alternate US/UK names, translated names, transliterations and everything else under the sun. It would be beneficial to figure out where we want to go with all this before we jump into the fray and start swinging the battleaxe :) Ahasuerus
The field is not structured enough for us to be able to parse English/non-English out automatically (and if we can, we can parse the Transliteration field the same way). There is no scenario under which we won't need transliterations for series (and if we go multiple fields, each of them will need a transliteration set attached). I understand what you mean but I really cannot see this work being undone in the long run no matter what we end up with. The only possible option will be for us to say that ALL series need English name and all the rest goes into the notes field - and that is very very unlikely. Annie 21:32, 19 July 2018 (EDT)
True. OK, I'll go ahead and create an FR. It will be some time before I can get to it anyway (Security Phase II is next on the list), so perhaps we'll think of something in the meantime. Ahasuerus 08:31, 20 July 2018 (EDT)
Perhaps it would be good to have an "official translation" field for the series only (since series don't have variants) in addition to the transliteration fields. Have it be similar in that multiple entries could be made (for example, if a Japanese series had official English, Spanish, Chinese, and Russian translated titles, all of them could be entered). Then that field could be added to the list of fields searched with "All titles" as well as "Series". Not sure about whether we would want transliteration fields for each of the official translation fields created. ···日本穣 · 投稿 · Talk to Nihonjoe 00:55, 26 July 2018 (EDT)

H. P. Lovecraft

I believe that Out of the Aeons, Out of the Eons, and Out of the Aeon might very well be the same story and should be combined, and variated. Anybody have any ideas? MLB 20:37, 18 July 2018 (EDT)

We also have Out of the Aeons already varianted under the main record so I would say that you are right and all of these are the same stories. Rtrace had verified books/magazines with two of those spellings - maybe we can ping him to check those 2? Annie 20:48, 18 July 2018 (EDT)
They're the same story. It appears that "Aeons" was introduced by S.T. Joshi in the corrected edition of The Horror in the Museum and Other Revisions. Unfortunately, neither his note on the texts nor his notes in Sixty Years of Arkham House mention the reason for the change in spelling. Joshi states that he only had access to autograph manuscripts or typescripts for a few of the titles in HITM, and this story was not one of them. The remainder were taken from their first magazine appearances with corrections made for spelling and stating that "we have reinstated Lovecraft's normal punctuation, stylistic and syntactic usages", which is a possible explanation. He further contends that Lovecraft wrote "nearly the entirety" of the stories he revised for Heald. Despite this, I would recommend that we use this title as the canonical title, which is as first published. --Ron ~ RtraceTalk 22:21, 18 July 2018 (EDT)
Will variant them soon. MLB 06:50, 19 July 2018 (EDT)

Fixer's "public" process is now official

It's been 5 days since this post and editors are beginning to use the new process. I guess it means that it's official now. We can tweak it if and when we run into issues. Ahasuerus 11:22, 21 July 2018 (EDT)

Title type mismatches -- change the rules and/or the cleanup report?

We have a moderator-only cleanup report which looks for title type mismatches between variant titles and their parents. (Naturally, it skips SERIAL variants and INTERIORART/COVERART mismatches.)

If I recall correctly, the original version of this cleanup report didn't support the ability to "ignore" mismatches because we figured that all mismatches should be invalid. However, later on we came across cases of what we considered to be legitimate mismatches. For example, Un monde magique is a French translation of Jack Vance's collection The Dying Earth. Unlike the English original, the translation "is presented as a novel (no TOC nor individual copyright notice for the stories", so it was entered as a NOVEL.

At this time we have 9 mismatches of this type:

We also have The Time Machine (abridged), a SHORTFICTION title, varianted to The Time Machine NOVEL and "Death Is a Lady" which exists both as an ESSAY and SHORTFICTION because:

  • The two versions of this title are the same, but the 1997 version is presented as a "true encounter with the paranormal", hence listed as non-fiction, while its later appearance is presented as a fictional story.

which seems questionable.

Finally, we have 17 apparently illegitimate mismatches which were "ignored" in error. (See my earlier post on the Moderator Noticeboard for details.)

Given the low number of legitimate "ignore" cases and the relatively high number of invalid "ignores", I can think of three ways to approach this issue:

  • Leave everything as is and ask moderators to be more careful with the "ignore" link
  • Remove the "ignore" link and handle what we currently consider to be legitimate mismatches differently: either force the title types to match or break the variant relationship (and add notes)
  • Move REVIEWs, by far the most common offender, to a separate cleanup report which wouldn't support the ability to "ignore" mismatched. Possibly INTERVIEWs and INTERIORART titles as well.

What do you think? Ahasuerus 15:28, 25 July 2018 (EDT)

I'd say get rid of the ability to ignore and force matches (or break relationships). FWIW, I don't agree with the treatment of the detailed example you cite. If a collection has been translated, it's still a collection, no matter the presentation chosen by the new-language editor/publisher. Unless, of course, there was more rework than simple translation, in which case there should be no variant relationship. --MartyD 11:28, 28 July 2018 (EDT)
I agree with Marty. I do not see how these above are different from Asimov's "The Foundation" for example - I did not even realize that there is a reason not to consider it a novel until I came here and yet, we somehow enforce our own rules :)
As for the essay/short-fiction example above - just because an author claims that something is true, does not change the type. It is either true or not, especially because it is the same text... Same for abridgments - either add them with the original type (and write notes) or don't variant (and add notes and connect via the notes). Annie 14:13, 28 July 2018 (EDT)
I agree re: abridgements, especially considering the fact that it affects only title.
"Essay vs. short fiction", on the other hand, is a more complicated issue. The standard that we currently use to decide whether something is speculative fiction is whether the text is presented as fiction, not whether it's true. If we used "truth" as the criterion, we would have to count hoaxes and fraudulent accounts of UFO abductions and the like as "fiction".
This particular case is unusual because the same text has been published both as fiction and as non-fiction. I would be inclined to list it as fiction and explain the details in Notes. Ahasuerus 14:38, 28 July 2018 (EDT)
I agree also that these cases can all be handled without type mismatch. The proposed solutions are good (French cases as collections with the note "presented as if it is a novel, with the story titles omitted;" "true" story as fiction, note on first publication).
As for the abridgment, as I understand it the standard practice is that if it's a great alteration (as opposed to, for example, the editorial decision to omit a couple of paragraphs, as has been known to happen) they should not be varianted. And we have some abridgments that are credited like retellings to author+abridger, although that isn't consistent. True, the situation is confused by the fact that abridged translations are varianted to the full original. We currently solve type mismatches between novella-length translation and novel-length original, or vice versa, by setting the translation to the same length as the original. I'm not entirely sure that's a good idea, but at least it prevents type mismatches. --Vasha (cazadora de tildes) 15:23, 28 July 2018 (EDT)

(unindent) Based on the discussion so far, I have "unvarianted" The Time Machine abridgement and merged the "true encounter" ESSAY with its SHORTFICTION equivalent.

Assuming that the mismatches posted on the Moderator Noticeboard can be resolved, all we have left is the 9 NOVEL mismatches listed at the beginning of this section. Of the 3 editors who have "primary verified" these publications, only one, Linguist, is currently active. I will ask him to chime in. Ahasuerus 11:02, 2 August 2018 (EDT)

For the sake of coherence in this db, I'd go along with removing the "ignore" link and forcing matches / breaking relationships. I'll tackle the pubs I'm a PVer of tomorrow (and, I suppose, the few French pubs I didn't do, if we take this decision). Linguist 12:09, 2 August 2018 (EDT).
Thanks for looking into this! I guess we'll end up with a few COLLECTION/OMNIBUS publications without Contents titles, but our cleanup reports are equipped to handle them.
If no other approaches are proposed in the next day or two, I will remove the "ignore" functionality from this cleanup report. Ahasuerus 12:46, 2 August 2018 (EDT)
I have marked all the French pubs as "done". Linguist 05:07, 3 August 2018 (EDT).
Thanks! The cleanup report has been updated to disallow the ability to "ignore" titles. Oops! I just realized that I forgot to make it available to non-moderator. I'll go ahead and fix it now. Ahasuerus 20:22, 3 August 2018 (EDT)
Done. Ahasuerus 21:21, 3 August 2018 (EDT)

Mike Stone as pseudonym

The name Mike Stone is pseudonymed to two authors, Melvin Berger and Michael Stone. As far as I can tell, this is simply erroneous (this is not a case where two authors wrote under a joint pseudonym). So we ought to split it and create another name, such as "Mike Stone (Melvin Berger pseudonym)." Furthermore, it looks like Michael Stone actually writes under "Mike Stone" more frequently. If we made Mike Stone the canonical form of his name, the two Mike Stone records wouldn't both be pseudonyms. Does this solution make sense to you folks? --Vasha (cazadora de tildes) 20:15, 26 July 2018 (EDT)

I don't think that's necessary. We don't split house pseudonyms into separate ones for each author that used it individually e.g. Kenneth Robeson. --Ron ~ RtraceTalk 07:03, 27 July 2018 (EDT)
That's because house names are all the same credit. They are intentionally using the same name and the marketing (for the most part) is that the books are all written by the same person. Two authors coincidentally using the same name isn't the same case. I don't believe we're consistent on how we handle the second case. I've seen it split out like Vasha77 is suggesting, but I believe I've also seen it not. In this case, Michael Stone's canonical name should be Mike Stone based on our standards. So making Mike Stone the canonical name for Michael Stone and disambiguating the Melvin Berger pseudonym makes the most sense to me. -- JLaTondre (talk) 10:32, 27 July 2018 (EDT)
I take back what I said about changing the canonical name; most of his books have appeared under both names, with Michael being slightly more frequent than Mike, so may as well leave it be. In that case we do have to decide what to do about splitting the pseudonym. --Vasha (cazadora de tildes) 11:44, 27 July 2018 (EDT)
Given that "Mike Stone" is a natural nickname form of "Michael Stone", I'd be inclined to leave that one disambiguation-free and disambiguate just the true pseudonym. I think using "(Melvin Berger)" would be sufficient -- no need for the extra "pseudonym" in there. --MartyD 11:22, 28 July 2018 (EDT)

Unknown vs No Cover Art

Just checking - there is no way to indicate that there is no cover art as opposed to I don't know who did it. ../Doug H 13:30, 29 July 2018 (EDT)

If there is no cover art, then you can add an explanation to the publication notes. -- JLaTondre (talk) 14:05, 29 July 2018 (EDT)
I've scanned the board cover, so looking at the publication, it is evident, as it would be looking at all covers for the title. But in terms of tracking publications that have no cover vs. those that will never have one, it's not so useful. I guess I was wondering just as much whether there had been any discussion over the years about this. Always interesting to pick at scabs. ../Doug H 14:17, 29 July 2018 (EDT)
I don't recall discussions of tracking publications without cover art. I guess the difference will become important if and when we create a cleanup report to look for pubs without cover scans. Let me think about it...
OK, so in the past a cleanup report like that seemed unfeasible because we had so many publications without scans. However, checking the database, I see that 440,713 of our 512,179 pub records already have scans. Of the 9,583 2018 pubs, 8,888 have scans. If you discount library bindings, it will be even closer. Perhaps we could create a cleanup report that would be broken up by year and allow "ignoring" pubs which are known not to have cover art? Ahasuerus 11:42, 30 July 2018 (EDT)
Having scans and having a cover artist are not really related though - as we do not record designers and the number of books with designed covers (as opposed to having an artist) is much much higher these days (a lot of the self-published stuff uses stock images), we still are looking at a lot of pubs that will need ignoring. Annie 11:55, 30 July 2018 (EDT)
True. Sorry, I started thinking about cover scans and got distracted. Ahasuerus 12:39, 30 July 2018 (EDT)
On the other hand, now we cannot connect covers that are actually the same but just have no artist. Which I had always considered a bit of a limitation :) Myabe we can come up with solution that solves both issues. Annie 13:05, 30 July 2018 (EDT)
I was actually thinking in terms of a "not applicable" standard for cover artist. But this is more fun. And cover scan vs. cover art vs. cover artist make three different things. ../Doug H 13:14, 30 July 2018 (EDT)
Maybe add a checkbox that sets the cover art to "none"? ···日本穣 · 投稿 · Talk to Nihonjoe 13:10, 3 August 2018 (EDT)
It wouldn't be hard to do, but would it have advantages compared to "No cover art" in the note field? Ahasuerus 19:38, 3 August 2018 (EDT)
Advanced Search - much easier to have a checkbox than try to control that everyone uses the same string/template. This way editors that specialize in the art titles can find the books that have a cover that has an author but we still had not discovered the artist. Annie 20:00, 3 August 2018 (EDT)
I am trying to visualize the use case, but I am not sure I have it right. Here is what I think I am hearing:
  • An editor wants to find a subset of publications (based on pub authors and/or publisher and/or other criteria) which have cover scans but no COVERART titles associated with it.
Is this correct? If so, is it safe to assume that a cleanup report wouldn't work because it would be too long, especially given the fact that "ignore" wouldn't be feasible in most cases? Would it help if the cleanup report was broken up by publication year? Ahasuerus 14:31, 13 August 2018 (EDT)

(unindent) My original question would have helped Annie's Advanced Search scenario only in eliminating some matches. I have scanned (old) covers with patterned board. So there is an image, but there is no cover artist. So if someone is looking for unidentified cover art, my 'flag' would eliminate some search matches. If there were a cover artist of "Not applicable", you would get the same effect. Putting the 'flag' in the notes is somewhat self-defeating, since if you can see the note, you can see there is no art or artist. A searchable 'tag' in the note (would a "No cover art" template be searchable?) would be also work. ../Doug H 14:54, 13 August 2018 (EDT)

seeking Le Troupeau Aveugle 1 cover in high resolution

Hello, ISFDB folks. I'm a graphic design historian writing about speculative fiction book covers that depict eco-dystopia and I'm seeking a high resolution scan of the cover of part 1 to the 1981 French edition of John Brunner's The Sheep Look Up, link to the relevant ISFDB page below. I have written copyright permission from the publisher to use the image when the article is published and I've ordered a hard copy of the book itself, but shipping between Germany and USA proved fatal to this undertaking and I can't find another vendor to order a different copy.

If any Brunner fans/collectors out there would be willing to share a 300 DPI color scan of your cover, I'd be eternally grateful if you'd get in touch by replying to this Help Desk comment!

LINK: http://www.isfdb.org/cgi-bin/pl.cgi?369591 —The preceding unsigned comment was added by Griffid1 (talk • contribs) .

Since the book was verified by Hauck in 2011, you may want to try sending him an email to see if he would be willing to scan the cover. The "E-mail this user" link on his User page should work. Ahasuerus 11:30, 30 July 2018 (EDT)

Bibliographic Warnings

I found this title with Bibliographic Warnings "Missing ISBN/Catalog #: The Halfling and Other Stories (1973-09-00)". Since there is a Catalog# 31590, I wonder if there is a software update useful? --Zapp 14:55, 2 August 2018 (EDT)

Oops, I must have missed it when I separated ISBNs and Catalog IDs. It should be fixed now. Thanks for identifying the problem. Ahasuerus 15:49, 2 August 2018 (EDT)

Mouseover bubbles tweaked again

As we discovered a few days ago, a mouseover bubble can sometimes cover the link that it is associated with, making it impossible to click the link. As near as I can tell, it only happens under Firefox and only when using certain magnification levels. Moreover, it's inconsistent at the same magnification level: you can get mouseover bubbles to display correctly if you use Control/+ and Control/- a few times, but if you hit Control-F5, the bubble will once again appear on top of the link.

Given these Firefox inconsistencies, it would be difficult to create a software workaround which would result in correct Firefox behavior under all circumstances. For now, I have implemented a workaround: mouseover bubbles have been modified to support the ability to click through them even when they cover the links that they are associated with. Hopefully it will address the immediate problem. You will need to do a full page reload (Control-F5 under most browsers) to make your browser support this functionality. Ahasuerus 15:22, 2 August 2018 (EDT)

Thanks a lot ! I had to work around the problem by copying the link and using the searching tool, it was getting a bit tedious ! Linguist 05:11, 3 August 2018 (EDT).
Sure thing! Ahasuerus 10:01, 3 August 2018 (EDT)
Works for me. Thanks! ···日本穣 · 投稿 · Talk to Nihonjoe 13:09, 3 August 2018 (EDT)

Magazine grid changes

As per ISFDB:Community_Portal#Magazines_with_multiple_formats and FR 1172, magazine grids have been tweaked. The software has been modified to:

  • Determine the most common format used by the displayed magazine
  • Display the most common format in the header
  • If there are issues with other formats, also display the words "(unless indicated otherwise)" in the header
  • For issues whose format doesn't match the most commonly used format, display the actual format next to the issue title

For example, here is the grid for Astounding / Analog (1937-1971). Note the line which says "Format: digest (unless indicated otherwise)" in the header. Also, if you scroll down, all of the non-digest issues have their formats displayed in square brackets. How does it look? Ahasuerus 19:30, 3 August 2018 (EDT)

I like it :) It does look a bit crowded on first glance but I actually think that it is crowded in a good way. Annie 20:01, 3 August 2018 (EDT)
very nice. --Vasha (cazadora de tildes) 22:03, 3 August 2018 (EDT)
I like it. ···日本穣 · 投稿 · Talk to Nihonjoe 00:31, 4 August 2018 (EDT)

ISFDB banner rotation

As most of you know, we have 10 ISFDB banners (images displayed at the top of all ISFDB pages) which are rotated nightly. The way banners are handled internally was changed a few minutes ago. You may need to do a full page reload (Control-F5 in most browsers) for everything to be displayed correctly. If you run into any issues, please let me know. Ahasuerus 16:38, 4 August 2018 (EDT)

Changes to stats reports

FYI, the way certain "stats" reports are generated overnight has been tweaked. There should be no user-experienced changes except that the affected reports will be unavailable until tomorrow morning. Ahasuerus 21:03, 5 August 2018 (EDT)

Computationally intensive statistical charts have been moved to the nightly process. Their data will be regenerated tomorrow morning. Ahasuerus 15:19, 7 August 2018 (EDT)
A new report, "Submissions per Year", has been added to the "ISFDB Statistics and Top Lists" menu. The data will become available tomorrow morning. Ahasuerus 20:32, 7 August 2018 (EDT)

Author stats by magazine

Could we add a tab (like the Awards, Chronological, etc., tabs) to author pages that listed how many times they appeared in various magazines? Perhaps updated monthly (or maybe weekly) since most magazines come out monthly? I had an author ask for this feature. Is this feasible? ···日本穣 · 投稿 · Talk to Nihonjoe 20:24, 6 August 2018 (EDT)

A couple of months ago we talked about adding a tab that would show a breakdown of author appearances by publisher. It's all feasible, although it may require some work. If there is enough support, I can create Feature Requests. Ahasuerus 22:45, 6 August 2018 (EDT)
I like that idea, too. ···日本穣 · 投稿 · Talk to Nihonjoe 13:22, 7 August 2018 (EDT)
OK, FR 1178 and FR 1179 have been created. Ahasuerus 14:15, 13 August 2018 (EDT)

BB Codes - First pass

As we briefly discussed during the rollout of the first phase of security-related changes, we will need to enhance the security of our Note fields. The current plan is to migrate all HTML tags to BB codes -- see this reference for a list of "standard" BB codes. The reason I put "standard" in quotes is that, unlike HTML, there is no single BB code standard which is universally acknowledged and enforced. In a way it makes our task easier because it gives us more flexibility to create custom, ISFDB-specific BB codes.

Explanation of the Problem

The problem that we are trying to address here is malicious submissions. As I wrote a few weeks ago on my Talk page:

  • The big problem with allowing arbitrary HTML in notes is security. A hacker can create a submission with an embedded script which will try to download malware/viruses to your computer. The most recent round of security enhancements implemented defenses against this type of attack, but they are only in effect for users who use modern browsers. If you are using something like Internet Explorer, you are still vulnerable. We need another round of security enhancements which will prevent Evil Things from being injected into submissions, which will probably mean migrating to BBCodes.

The most obvious solution -- the one that I considered first -- would be to continue allowing HTML in notes and to "sanitize" all entered text to prevent malicious scripts. Unfortunately, it's enormously difficult to do. Facebook, Twitter, Wikipedia, CNN and many other major sites failed to implement sanitizing correctly and comprehensively when they first rolled out their software. It took dozens, probably hundreds (perhaps thousands) of developer man-years to get most things right. Moreover, it's a moving target as HTML standards and browsers change and hackers come up with clever new ways to insert malicious scripts.

The second most obvious solution would be to find an existing freely available HTML "sanitizer". At one point I spent a significant amount of time looking into this option. It would be more viable than creating a homegrown sanitizer, but it would still be time-consuming and error-prone to implement. Here are some of the issues that I came across:

  • Third party sanitizers have software requirements and dependencies which would force us to change our software in significant ways.
  • We would have to rely on their maintainers to keep their code up-to-date in a timely fashion; we would then have to monitor their work and apply their patches to our version of their software.
  • The way we encode and decode submissions internally would mean that we would have to change any third party sanitizer before they would work with our software. Over time it would make it difficult to keep our version in sync with the main version.

The fundamental security problem with HTML is that it mixes text and browser instructions (like <a href=>) in a free-form way which makes it easy to present user-entered data (in our case submission data) as browser instructions. This is the root cause of the difficulties which even powerhouses like Facebook and Twitter had with HTML sanitizing early on -- the HTML design makes it difficult to separate user-entered data from browser commands. See the famous XSS Filter Evasion Cheat Sheet for over a hundred examples of different ways to insert malicious codes in user-entered content. As long as you allow "<" and ">" in user-submitted data, you have to deal with this Pandora's box of vulnerabilities.

The question then is: if HTML sanitizing is prohibitively difficult to implement, then what is the alternative? The obvious answer is to convert all entered angle brackets to their corresponding "HTML entities": "<" becomes "& lt;" and ">" becomes "& gt;". They will be displayed as angle brackets and browsers will no longer interpret them as instructions. Of course, the downside to this approach is that it prevents your users from entering any kind of HTML hyperlinks or formatting: bolding, italics, etc. If you want to allow them, you need an alternative way of entering them which will be displayed as HTML at display time. That's why BB Codes, Wiki formatting and other alternatives were developed in the late 1990s and early 2000s.

As to why the currently proposed solution is BBCodes as opposed to Wiki formatting, the main issue with Wiki formatting is that it supports a subset of HTML codes. It once again raises the issue of HTML sanitizing and reopens the Pandora's box which we are trying to close.

The other issue with Wiki formatting is that even the non-HTML part would take a significant amount of work to implement. There are third party tools which can do it for you, e.g. mwlib, but third party tools come with problems of their own as discussed earlier. BBCodes, on the other hand, are very straightforward to implement. (Except for "[url]", but that's a relatively minor headache compared to the alternatives.)Ahasuerus 11:11, 11 August 2018 (EDT)

Currently Used and Supported HTML Tags and Their BBCode Analogs

I have examined the Note fields of all of our records and here is what I found:

Supported HTML tags currently not in the database

  • abbr
  • h1
  • h2
  • span

There are no standard BB codes for these tags. Since we currently don't use them, I propose that we simply disallow them going forward. [Edit: Done.]

HTML tags with no standard BB Code replacement

  • !--isfdb specific--: 3790
  • br: 115362
  • caption: 1
  • hr: 1
  • q: 3
  • sub: 2
  • sup: 28

The numbers show how many times each tag has been used. Given these results, I suggest that we disallow "caption", "hr", and "q". [Edit: Done.] We can create custom BB codes like "[br]", "[comment]", "[sub]" and "[sup]" for the other four tags.

HTML tags with no conflicts with their BB replacement

  • center: 22
  • li: 94355
  • ol: 103
  • pre: 1 [code]
  • table: 240
  • tbody: 1
  • td: 240
  • th: 220
  • tr: 240
  • u: 96
  • ul: 95279

I suggest that we disallow "pre" and "tbody". [Edit: Done.] The rest of these tags should be OK.

HTML tags with conflicts with their BB replacement

  • b: 5877 [b] 5
  • blockquote: 77 [quote] 1
  • cite: 98 [i] 18
  • del: 14 [s] 159
  • em: 3990 [i] 18
  • h3: 5 [b] 5
  • i: 60174 [i] 18
  • p: 888 [p] 1
  • s: 7 [s] 159
  • strong: 67 [b] 5

(The fist code is the HTML tag followed by the number of times the tag is currently used in the database followed the replacement BB code followed by the number of times the BB code is currently used in the database.) [Edit: "h3" has been eliminated.]

Analysis

"[quote]" and "[p]" have one conflict each, so we should be able to come up with manual workarounds for them. "[b]" is used 5 times, mostly not in direct quotes, e.g. see this publication, so we should be able to replace it as well.

Now comes the tricky part. As you can see, there are quite a few occurrences of "[i]" and "[s]" in Notes. If we were to start using them as BB codes, we would have a conflict.

"[s]" is the main offender, but we could use "[del]" instead of "[s]" as our BB code for deleted text, which should resolve the conflict. There are only 21 "del" and "s" HTML tags, so it's not like most editors need to use the functionality regularly.

"[i]" (18 occurrences) is the most problematic one. Some, e.g. this pub, we can easily reword. Other notes, e.g. this one contain direct quotes which include "[i]". I am not sure what the best way to address them would be. Perhaps change them to their ASCII codes, i.e. & #91; and & #93; ? Ahasuerus 19:34, 10 August 2018 (EDT)

Step 1: except for [s], replace all existing faux-bbcodes with ascii codes. Step 2: Create a cleanup report looking for new faux-bbcodes. --Vasha (cazadora de tildes) 19:52, 10 August 2018 (EDT)
Why not use wiki formatting instead of bbcode? Why introduce a new formatting scheme for people to learn when we already have one? -- JLaTondre (talk) 09:17, 11 August 2018 (EDT)
Sorry, I understand why, but I ask the same question rhetorically, as a complaint. HTML is bad enough, Wikitext is already worse, and BB codes will be worse beyond that in terms of familiarity and usability. While some of us in the ISFDB community are technical, and any method of encoding is merely a matter of finding the right reference material, a large portion of the community is non-technical. Picking something that most of the community is unlikely to be familiar with -- and won't be using in any other context -- and that conflicts with a style used in natural writing, doesn't seem like a good idea to me. I'd be inclined to continue to allow HTML, blacklist most of it, and then use something like the OWASP sanitizer. Easy for me to say. --MartyD 07:24, 12 August 2018 (EDT)
Thanks for chiming in! I have been thinking about our options for the last 24 hours and it occurs to me that we may be overlooking an important angle here. There are three elements to the Notes issue:
  • How our users enter notes
  • How the database stores notes
  • How the software displays notes
These issues are linked, but they are not necessarily identical. Specifically, whatever we use to store formatting information -- HTML, BB Codes, Wiki formatting or something else -- need not dictate the user interface. If we were to add a rich text (WYSIWYG) editor to our data entry forms, it would eliminate the need for our editors to learn HTML/BB codes/etc and mask most of the underlying complexity. There are many free JavaScript-based WYSIWYG editors out there and it may be possible to add one of them to our software without too much pain.
What do you think? Ahasuerus 12:08, 12 August 2018 (EDT)
WYSIWYG is a great idea, if you can find one that you can plug in without too much difficulty. --MartyD 12:24, 12 August 2018 (EDT)
Good questions. I should have started this discussion with an explanation of the reasons behind the proposed move to BB codes. [Edit: Explanation moved to the top of the section Ahasuerus 13:01, 12 August 2018 (EDT) ]
I understand the HTML issue, -- JLaTondre (talk) 11:39, 11 August 2018 (EDT)
I suspected that you would be familiar with most/all of these issues, but I figured it would be a good opportunity to put them on paper for everybody to review and for future reference :) Ahasuerus 13:50, 11 August 2018 (EDT)
but that is irrelevant to wiki formatting. Wiki formatting does not use any HTML codes. Wikimedia software allows you to use HTML intermixed with wiki formatting, but that is not the same thing. -- JLaTondre (talk) 11:39, 11 August 2018 (EDT)
Oh, I see. You were referring to "wiki formatting" proper, not to the superset supported by our Wiki software. Ahasuerus 13:50, 11 August 2018 (EDT)
If you are going to implement the parsing all yourself, -- JLaTondre (talk) 11:39, 11 August 2018 (EDT)
At this time we don't use any third party software beyond MySQLdb which lets our software connect to the database. Given my painful experience with third party dependencies in a prior life, I am very hesitant to add dependencies unless we absolutely have to. The memories of Y2K remediation when numerous dependencies on dead projects resulted in otherwise salvageable software packages getting retired (at a huge cost) still haunt me. Ahasuerus 13:50, 11 August 2018 (EDT)
than I understand the desire for going with what is easiest to parse. But neither one is going to be easy. You are going to find a lot of edge cases. -- JLaTondre (talk) 11:39, 11 August 2018 (EDT)
It's my understanding that most of the complexity and the edge cases come from supporting tag parameters, e.g. see this list BBCode vulnerabilities. With the exception of "a", none of the HTML tags that we currently use (see the list above) require parameters, so we should be in reasonably good shape. I am actually in the process of scanning notes for HTML tags with parameters, which I will then convert to parameter-less tags. Ahasuerus 13:50, 11 August 2018 (EDT)
I have finished the scan. With the exception of "a", we have 23 tags with parameters, all of them tables-related. I plan to clean them up later today. Ahasuerus 14:46, 11 August 2018 (EDT)
I can also understand the architecture issues with including third-party libraries, but only to an extent. Unless you are going to copy-n-paste the code through the baseline (hopefully not), you are going to have to deal with structuring the code so that the parsing can be called from multiple places. As for third party libraries, rely on a package manager (either pip or OS level) for that. -- JLaTondre (talk) 11:39, 11 August 2018 (EDT)
Regardless of which one used, it should support the ability to "escape" codes (wiki has <nowiki></nowiki>) that will produce straight text. Use that to escape all existing "codes" in the database. If it will be BBcode, we should stick with the standard version vs. creating a unique dialect. -- JLaTondre (talk) 09:17, 11 August 2018 (EDT)
The BB Code guidelines (I hesitate to call them standards because I have been unable to find any standards organizations or documents) do not seem to support a standard way of escaping square brackets. Also, the original BB Code convention was apparently to use "[list]" for lists, but modern implementations support the HTML-derived "[ul]" and "[ol]" as well, which is another example of how nebulous it is.
Thinking some more about it, what stands out is that all we need is software support for a very limited number of formatting elements:
  • italics, bold, underline, strike-through
  • lists
  • simple tables
  • new paragraph/new line
  • hyperlinks (http and https only)
None of them (with the exception of hyperlinks) need parameters. Once we clean up the existing HTML in notes, we'll just need to support the following HTML tags in some fashion:
  • p
  • br
  • ul
  • ol
  • li
  • table, th, tr, td
  • u, b, i, del
  • blockquote
  • perhaps sub/sup (2+28 in the database)
Only one of them, "i", has a non-trivial conflict with "[i]" in the existing data; "<i>" could be replaced with "<em>", another standard HTML tag. Then there is "a", which is the only tag that requires a parameter.
From the implementation perspective and the usability perspective, perhaps the easiest way to get this done would be to say that we support a very limited subset of HTML tags (see the list above) in notes, but you have to use square brackets instead of angle brackets, just like you do with BB Codes. Technically, we would be using extended BB Codes (p, br, del, blockquote instead of quote), something that many BB Codes packages apparently support. Ahasuerus 15:37, 11 August 2018 (EDT)
We previously noted that it would be useful to have custom table tags so that you could choose to either have borders between your cells or not -- some existing tables would look better with them, some without. --Vasha (cazadora de tildes) 19:17, 11 August 2018 (EDT)
Yes, I remember that discussion. At first I thought that all of our tables would benefit from cell borders, so I figured we could just make the "[table]" BB code generate borders. However, later I came across publications like this one where tables are used to position text on the page in a way that mimics certain segments of the text in the book. It's not very common, but there may be other cases like that (series, awards, etc) and we'll need to account for them. Ahasuerus 21:03, 11 August 2018 (EDT)

Software Changes

The low-hanging fruit -- hr, q, caption, h1, h2, h3, span, abbr, and tbody -- has been disallowed. The cleanup reports have been updated and most of the offenders have been manually replaced with functional equivalents. There may be one or two left; we'll find out tomorrow morning once the nightly process runs. Ahasuerus 22:31, 11 August 2018 (EDT)

Tentative Outcome

Based on the discussion above, it looks like I need to go back to the drawing board, re-evaluate the proposed solution and investigate our WYSIWYG options. I also need to further clean up the data entry components of our software. Thanks to all the participants! Ahasuerus 16:25, 12 August 2018 (EDT)

Ruby Characters

I’ve entered a lot of phonetic transliterations for Japanese in either Hiragana or Katakana. It occurred to me that support for Ruby Characters or phonetic renderings above the Kanji or Chinese characters would work better. Examples for various Asian languages on the wiki page for Ruby Characters.--Rkihara 11:47, 13 August 2018 (EDT)

I see that older versions of HTML had spotty support for Ruby markup, but the HTML 5 standard added full native support. Among modern browsers, only Firefox fully implements the standard. Other browsers provide partial support, which should be good enough for our purposes.
We'll have to do at least 2 things to add Ruby support to our software:
  • upgrade our version of HTML from 4.01 to 5
  • redesign transliterated names to support Ruby
We'll need to do the HTML upgrade for other reasons anyway. Once we do that, we'll need to decide how many developer man-hours we want to spend on redesigning transliterated names. For now, I will create an FR and we'll revisit it once the HTML 5 upgrade is done. It will also give the rest of the world, including our users and editors, more time to catch up on the browser side, e.g. Linguist's version of Firefox doesn't support Ruby. Ahasuerus 14:02, 13 August 2018 (EDT)
FR 1177 has been created. Ahasuerus 14:10, 13 August 2018 (EDT)
One thing to keep in mind with Ruby characters: if you want it to be accurate, we have to find a way of applying them per character. This is how it is generally done in Japan. ···日本穣 · 投稿 · Talk to Nihonjoe 12:32, 15 August 2018 (EDT)
Thanks. That's what I thought, but I couldn't be sure. I expect that it won't be easy, but you never know until you try. Ahasuerus 21:38, 23 August 2018 (EDT)

Lodestar Award

This year the World Science Fiction Society (WSFS) presented a new award young adult speculative fiction at the Hugo ceremony. While not a Hugo, the award is nominated and voted on by the members of the Worldcon. I think that we should add this award and I'll happily enter the data. I would have asked to add this earlier when the nominations were announced, but at that time the award had not yet been named. For technical reasons in the WSFS constitution, the name "Lodestar Award for Best Young Adult Book" was not ratified until this year's Worldcon and is not retroactive for the inaugural year. However, I think we should use the name as it will continue and I can add a note on the award page that for 2018 (only) the award was the "WSFS Award for Best Young Adult Book". Thanks. --Ron ~ RtraceTalk 19:50, 23 August 2018 (EDT)

I support adding this award. ···日本穣 · 投稿 · Talk to Nihonjoe 20:04, 23 August 2018 (EDT)
Works for me. Ahasuerus 21:35, 23 August 2018 (EDT)
I support that as well. Annie 22:40, 23 August 2018 (EDT)
The new award type has been created. Ahasuerus 09:21, 24 August 2018 (EDT)

Translations and translators

Hello. I read the design notes on translations and translators, but couldn't quite understand if the following cases would be covered by the current proposal or not. So I thought why not list it here and ask for feedback. :-)

  • A translated work attributed to a pseudonym of the translator, and a later printing of that same translation attributed to the legal name of that translator. I guess this is similar to Title varianting where the authors are differently spelled.
    Example: Warner Flamen is the pseudonym of Mark Carpentier Alting (accidentally also an author), and has De andere hemel (1975) translated by Flamen, and De Andere hemel (1988) by Alting.
    Example: Annemarie van Ewijck (legal name), Annemarie Kindt (name used when married to Leo Kindt), and Annemarie van Ewyck (supposedly used to distance herself from her father)
  • Two different translators using the same pseudonym
    Example: Venugopalan Ittekot was initially (1991-2005) used by Ruurd Groot, and later used by his wife Mieke Groot (2005-) - both translators - for the Dutch translations of Terry Pratchett's Discworld series.
  • Translation & later revised translation by the same translator
  • Two translators for a single title (already covered in the proposal)

BTW, are there articles & discussions elsewhere on the wiki about translations & translators? Thanks! MagicUnk 11:28, 24 August 2018 (EDT)

Oh dear... I had no idea that Requirements:Translations was still alive! It's been mostly superseded by the changes made in 2010-2016, so the text needs to be drastically revised.
That said, you raise some very good points. They are mostly in line with what we have discussed over the last few years. I think the most recent comprehensive discussion is here. It mentions some (but not all) of the scenarios that you listed. Ahasuerus 14:13, 24 August 2018 (EDT)
What I mean to ask is, has any progress been made in adding translator support? I understand that it is embedded in a discussion around implementing roles, but as we are now preparing for adding translator to a title by using the tr-template, wouldn't it be better to have an additional field added to the title record, at least as a small incremental improvement? (well multi-field to at least cover the case where two or more translators have contributed to the translation of the title). This would of course not cover the case where you had a later printing of the same title with another name for the same translator (the pseudonym case), as the software does not (yet?) support variant of variant... but still. MagicUnk 15:06, 25 August 2018 (EDT)
It's certainly possible that we'll roll out translator support incrementally, which is how we added language support in 2010-2016. However, we really need to have a solid design, an understanding of our ultimate destination, first. At the moment, we don't have one. We want something that would support all of the scenarios that you listed plus other things like:
  • transliterated translator names
  • combined author/translator bibliographies
  • awards given to translations
Without a solid design, we don't know what kind of database structures and software solutions we'll need, so creating a multi-field that would replace the "Tr" template may or may not be a step in the right direction. It would involve a fair amount of development work and may need to be completely redone later on. Ahasuerus 18:39, 25 August 2018 (EDT)
Makes sense. Thanks for the clarification. MagicUnk 02:24, 26 August 2018 (EDT)

Nominating JLochhas for moderator

See Moderator Qualifications#Becoming a moderator for the nomination process.

I am nominating JLochhas (talk) for moderator. JLochhas has been an active editor since 2009 with over 48k edits. He is experienced with all publication types and has good communication skills. One thing that impresses me is that I have seen him making corrections shortly after having a new pub accepted. We all make typos so I don't consider that a negative. Rather, that he regularly double checks his work is a strong positive. Given the number of his contributions, even if he only self-moderates while he learns the ropes, it will be a benefit. I am comfortable he meets the Moderator Qualifications and he has accepted the nomination.

Support

  1. Support, as nominator. -- JLaTondre (talk) 17:09, 24 August 2018 (EDT)
  2. Support. Seems to be doing a good job. I see no negatives here. ···日本穣 · 投稿 · Talk to Nihonjoe 17:56, 24 August 2018 (EDT)
  3. Support. There went my daily German practice... :) Never had issues with John's submissions and he seems to be retaining reminders about new/uncommon rules pretty well when they are pointed out to him. Annie 23:24, 24 August 2018 (EDT)
  4. Support. Due a long time. Stonecreek 00:19, 25 August 2018 (EDT)
  5. Support. No objections at all, everything is of high quality. Jens Hitspacebar 04:29, 25 August 2018 (EDT)
  6. Support. His work on the German 'hefte' is fabulous. Willem 05:57, 25 August 2018 (EDT)
  7. Support. I haven't come across any issues with his submissions in a long time. Ahasuerus 09:52, 25 August 2018 (EDT)
  8. Support. Ditto for everything stated above. :-) --MartyD 13:36, 26 August 2018 (EDT)

Oppose

Comments/ Neutral

Outcome

The nomination passes. The moderator flag has been set on JLochhas's account. Ahasuerus 19:09, 29 August 2018 (EDT)

Inadvertent overwriting of cover art

Hi Ahasuerus. I came across following situation where you could overwrite cover art of another publication than the intended one. If you have a pub1 with date 2000-00-00, say, with uploaded cover art abc2000.jpg, you then clone pub1 to pub2 with date 2001-00-00 for the latter. This 2nd pub will have cover art abc2000.jpg (and not abc2001.jpg which it should have). Now, assume you discover that pub1 had a wrong cover scan and you want to upload the correct one; then when you upload another version of the cover art for pub1, it will still be named abc2000.jpg, and as a consequence will also have updated the cover art for pub2. As pub2 had the correct one to begin with, this update results in pub2 now having the incorrect art. I've updated both pubs of this title this way, with the described result. I guess that in practice this situation will not happen often, but still... Note that if you would have uploaded new cover art for pub2 instead, it would've created a new filename abc2001.jpg, which URL you had to copy over into the pub (and get the edit approved).
Ensuring that when cloning a pub the cover art file gets copied and renamed to a unique filename would solve this issue - for as far as naming algorithm of cover scans otherwise creates unique names.
In addition, I also noticed that you can upload a new cover scan without moderator approval. Is that the intended behaviour? MagicUnk 14:59, 25 August 2018 (EDT)

Thanks for the heads-up! I will do more digging once I wrap up Fixer's catch for this month. This iteration is particularly bountiful because September-October tends to be the busiest season in the publishing business. Ahasuerus 18:18, 25 August 2018 (EDT)
While looking into it some more I also noticed that for the case where you upload another cover scan and overwrite the existing file, the name of the scanner is not updated in the fair use data section of the Wiki page either - for an example see here: Image:HSCRRNFNRX2001.jpg: my scan, Willem's name. MagicUnk 02:49, 26 August 2018 (EDT)

"non-genre" marker is used inconsistently for non-genre magazines

I just saw that the "non-genre" marker seems to be used completely inconsistently for non-genre magazine. Some series don't use it at all (example), some use it rarely (example), some use it mostly (example), and some use it always (example).

To my knowledge, these should all be "non-genre" throughout, or am I missing something? Jens Hitspacebar 07:23, 26 August 2018 (EDT)

In general, yes, they should all be marked non-genre (exception would be issues that are dedicated to genre, but that is a infrequent occurrence). Many of the relevant magazine entries pre-date the existence of the non-genre flag. Everyone once in awhile, I pick a magazine or two to fix, but it's a low priority for me. They can be found via this search (not everything there is non-genre, but the majority are). When doing this, it's a also a good time to add webpage links, descriptions, etc. to the author and series pages. -- JLaTondre (talk) 08:36, 26 August 2018 (EDT)
Ok, thanks. I just wasn't sure if there was some undocumented current practice I wasn't aware of. If the non-genre flag was added later to the software some of the discrepancies make sense now. Jens Hitspacebar 09:01, 26 August 2018 (EDT)

Canonical name change: Jei D. Marcade

Jessica J. Lee should have their canonical name changed to Jei D. Marcade. Recent web pages: Twitter, Escape Artists. If no one objects, I will make the change in two days. --Vasha (cazadora de tildes) 21:07, 26 August 2018 (EDT)

Seems logical. Ahasuerus 12:49, 27 August 2018 (EDT)
Looking at the stories we have, even without the rest of the links, I would have said that we should be changing it :) Annie 14:37, 27 August 2018 (EDT)

Title disambiguation -- a software approach

The ongoing discussion of SERIAL disambiguators on the Rules and Standards page got me thinking about the larger issue of title disambiguation.

We typically handle record disambiguation by adding a unique parenthetical disambiguator. We use this approach for authors, publishers, publication series, series and award categories (see the list of categories associated with Kurd-Laßwitz-Preis.) It's pretty much unavoidable because the software expects author names, publisher names, etc to be unique. We can't have 2+ authors named "Steven King", so one of them becomes "Stephen King (I)", another one "Stephen King (artist)", and so on.

On the other hand, titles and publications don't have to be unique. You can have 10 identical titles (or even 11,000+ titles like "Introduction") and it won't cause any problems for the software. We can choose to disambiguate, but we don't have to. And so we have come up with the following disambiguation rules for title records:

  • Parenthetical disambiguators of the following types:
    • For common essay names like "Introduction" and "Afterword", we add the name of the book where the essay appeared
    • For non-unique serial titles, we add "(Part X of Y)"
    • For novel-length works published in a single magazine/fanzine issue, we add "(Complete Novel)"
    • For poems written by the same author which share the same title, we occasionally add the first line of the poem
  • For omnibuses, we have a special field, "Content", which contains title-specific information and can serve as a disambiguator. For example, consider the following 2 omnibuses:
    • The Lunar Chronicles (2016) [O/1-4,0.5]
    • The Lunar Chronicles (2018) [O/0.5-4+coll]
  • For most other fiction titles, we don't add anything, which can be problematic when the same author is responsible for multiple works with the same title. As I wrote when we were discussing Roadmap 2017:
    • H. P. Lovecraft's Summary page shows three "The Lurking Fear and Other Stories" collections published in 1947, 1964 and 1971. They are all different, but you can't tell until you drill down to the title level and check each title's Note field. Similarly, there are 2 version of the story "The Rats in the Walls" (1924 and 1956), 4 "[To Albert A. Sandusky]" poems and 9 (sic!) poems whose title is currently entered as "[To ?]". Analogously, Clark Ashton Smith wrote 4 different "Ennui" poems, 2 different "A Sunset" poems, 3 "sonnet" poems, etc.

Basically, we have at least 3 different ways of handling non-unique titles, including our old friend the parenthetical disambiguator. It's not terribly consistent and, perhaps more importantly, it gets us further away from our goal of recording data "exactly as stated".

Back in early 2017 I proposed that we add a new "disambiguator" field and move the disambiguation information to it. There was limited feedback, so the idea was left out of "RoadMap 2017".

After mulling it over some more, it occurs to me that we already have a field -- conveniently called "Content" -- which serves a similar purpose. Currently it's only used for omnibuses, but there is nothing stopping us from using it as a general purpose disambiguator for all title types. We could keep the current data entry rules except that any disambiguation information for generic essay names, poems, SERIALS, etc should be entered in the Content field. We could also use it for things like "abridged", "expanded", "14 story version", etc.

Advantages:

  • It would get us closer to the "enter data exactly as stated" ideal.
  • Easy to implement. We would just have to adjust the software to display the value of the "Content" field for all title types and to tweak a few other minor things.
  • We could move the vast majority of currently existing disambiguators from the "Title" field to the "Content" field automatically (but see below.)

Disadvantages:

  • Currently, when entering Contents titles in a NewPub, AddPub or ClonePub data entry form, you enter parenthetical disambiguators in the Title field. If this change is made, editors will have to wait for the submission to be approved and then go back and populate the "Content" field of the newly entered titles. One way to address this issue would be to add the "Content" field to the set of fields available in the Contents section of our data entry forms. It's not trivial, but it should be doable.
  • The automatic migration of the currently existing disambiguators from the "Title" field to the "Content" field may present a problem in certain cases. Some introductions/forewords actually say "Introduction ([title])" in publications, so the parenthetical part should be left in the Title field. There is no way to be sure short of checking thousands of pubs.

So, what do you think? Ahasuerus 17:17, 27 August 2018 (EDT)

You know what, I really like this idea. The (excerpt) notations would go there too. --Vasha (cazadora de tildes) 17:36, 27 August 2018 (EDT)
"(excerpt)" is a thorny area. Functionally, it's a different data element, arguably a separate title sub-type which, 99 times out of 100, only applies to SHORTFICTION titles just like "novella", "novelette" and "short story".
Also, consider the fact that many stories have had multiple textually different excerpts published. If we were to move "(excerpt)" to the proposed content/specification/disambiguation field, we would have to squeeze 2 different data elements into it: "(excerpt)" and a disambiguation note like "2012 version".
I suspect that the right way to handle these beasts would be to add a fourth title sub-type, "excerpt". Unlike the other 3 sub-types, it would be displayed on Bibliography pages. Ahasuerus 14:09, 28 August 2018 (EDT)
Yes, agree w/ type for excerpt --Vasha (cazadora de tildes) 16:25, 28 August 2018 (EDT)
Some thought might have to go into how to display this on summary pages--it would usually be good to have it displayed (omnibus contents already are) but we'd have to see how cluttered longer specifications make things. --Vasha (cazadora de tildes) 17:36, 27 August 2018 (EDT)
Let me check the database... The "Content" field (as it exists now) supports up to 254 characters, but the longest value on file is under 40 characters long: 3,5,11,14,16,19,20,22,25,39,41,44,46.
I agree that displaying long strings of data would be bad. However, keep in mind that we already display the disambiguation data as part of the Title field. If we move it to a different field, the total amount of displayed text would remain the same, give or take a certain amount of formatting. Granted, having a separate field may encourage editors to enter longer descriptions that ought to be put in the Notes field. Perhaps we should add a moderator warning for values in excess of 50 (?) characters. Ahasuerus 13:58, 28 August 2018 (EDT)
I also like this idea. I think showing the Content (or whatever it ends up being called) field during title entry would help a lot. ···日本穣 · 投稿 · Talk to Nihonjoe 13:40, 28 August 2018 (EDT)
I like it, too. The idea of adding "excerpt" as a new title sub-type is a good one as well. But what about Omnibuses which have the content field filled and are also disambiguated (like this and its twin)? How would you enter one of these in one field? With a delimiter like "1-5;Uncut"? Jens Hitspacebar 15:54, 28 August 2018 (EDT)
Good point. Our early decision to squeeze different types of data into the same field invariably led to problems. Eventually we had to split all of our "overloaded" fields, in one case into 6 (sic!) different fields. If we have learned anything from prior experience, it's that we shouldn't be trying to overload fields going forward.
So if we are to do this right, we need to go back to the original proposal (made in 2017) and create a separate "Disambiguator" (or whatever we decide to call it) field. It would take more work, but nothing insurmountable. Ahasuerus 19:57, 28 August 2018 (EDT)
I also like the idea. We probably should spend sometime thinking about the desired uses and recommended wording for each. It won't prevent all variances, but if we can capture most common ones (excerpt, introduction, foreword, etc.) in the help that should reduce the problems. -- JLaTondre (talk) 19:47, 28 August 2018 (EDT)
I also like the idea. It will also help with the non-English titles where now we have all kinds of weird English strings in the titles.

Merging Titles After Adding the New Field?

We will have to do some merging after all that is done though - we have a lot of essays that are the same but are in different books so we had varianted them (and not they will be mergeable)... Which means that the contents will need to get the differentiation from all of the newly merged titles so we need to think about that. Or am I overthinking it? That's where I would be worried for the length of those fields... Annie 19:54, 28 August 2018 (EDT)

I think it's a valid point which we'll need to consider. It also reminds me that we will need to update the Duplicate Finder logic so that it wouldn't list identical titles with different disambiguators as merge candidates. Ahasuerus 20:00, 28 August 2018 (EDT)
So let's consider the following scenario. Stephen King's 11/22/63 has also appeared as "11.22.63". (Its translations have appeared as "22.11.63", "22/11/63", "22-11-1963", etc but we don't have to worry about merging translations.) The afterwords are currently recorded as Afterword (11/22/63) and Afterword (11.22.63) respectively.
Once the proposed disambiguator field has been added, do we want to:
  • merge the 2 Afterword titles and enter something like "11/22/63 and 11.22.63" as the disambiguator value, or
  • keep the 2 Afterword titles, but move "(11/22/63)" and "(11.22.63)" to the new field
? Ahasuerus 14:41, 31 August 2018 (EDT)
Same text, same title, same author, same language - isn't that out definition of a merge candidate pair ? :) The only reason they are different now is because they happened to be in separate books and we "invented" new names for them. As long as we figure a good way to show the disambiguation when you look at someone's author page (so we do not have 20 Afterwords that we cannot differentiate), that makes sense. Annie 14:55, 31 August 2018 (EDT)
That's right, the current title uniqueness criteria are:
  • the same author(s)
  • the same title
  • substantially the same text (minor textual variations do not count, but different translations do)
However, at this time titles include "embedded disambiguators", which make otherwise identical title records unique. If we are to move these disambiguators to a new field, we need to decide whether we want to add "the same disambiguator" to the list of uniqueness criteria. Ahasuerus 16:57, 31 August 2018 (EDT)
[I've cut out the text that I had been typing this morning as it's too convoluted - for those interested, I've copied it over to User:MagicUnk#Note on title disambiguation]. -- MagicUnk 06:24, 1 September 2018 (EDT)
OK, here goes. The different cases are:
  • same title, same contents, same author, different pubs. These can be disambiguated by referring to the 'canonical' title (is that the correct term?). In the Stephen King example above, titles would be merged, and disambiguated by referencing title 11/22/63, to which all the others are VT'd. So: Afterword (11/22/63), and appearing in all pubs where there's the same afterword in the contents.
  • same title, different contents, same OR different author, different pubs. Would be basically the same, isn't it? Reference the title to which the pub belongs, with an additional 'modifier' if the contents has been reworked between editions and you want to make that clear.
There's of course the corner case where the Afterword (11/22/63) appears in another pub with a different title altogether, but then again, wouldn't be bad to stick with the (11/22/63) ambiguator and have it merged with all the others referring to the same piece of text.
So I guess, the short answer is: yes, the disambiguator should be part of the uniqueness definition if we apply the above approach. (Does all of this makes any sense?) MagicUnk 06:24, 1 September 2018 (EDT)
The part that I don't think I understand is the second bullet. "Same title, different contents, same OR different author, different pubs" -- wouldn't that mean that the title records are different? Ahasuerus 17:04, 5 September 2018 (EDT)
Yes they are, they are identified solely by their disambiguator value (different author isn't relevant here as this is already part of the uniqueness check - same title, diff author doesn't get merged, does it?) , so that's why I think the disambiguator field must be part of the uniqueness check - or differently stated: don't merge if two titles are the same, but have different disambiguators MagicUnk 18:37, 5 September 2018 (EDT)

Title disambiguation: label of the field

The field should be called "Specification" rather than "Content." --Vasha (cazadora de tildes) 17:36, 27 August 2018 (EDT)

I agree that "Content" is not a good match for the proposed functionality. However, I am not sure that "Specification" would be intuitive/clear either. Unfortunately, nothing better comes to mind. Ahasuerus 13:48, 28 August 2018 (EDT)
<after thinking about it> Perhaps "annotation"? Ahasuerus 14:11, 28 August 2018 (EDT)
Not fond of that. This isn't any old annotation/note that would go in the notes field, this is just something necessary to distinguish the title and reduce confusion. --Vasha (cazadora de tildes) 15:10, 28 August 2018 (EDT)
As for a proper label I have no idea. "Version" comes to mind, but people may think that it means "printing". Or "Content description" instead of "Content"? Not fond of "Annotation" as well - it seems less intuitive than "Content". Jens Hitspacebar 15:54, 28 August 2018 (EDT)
If you're not afraid of a long name, "distinguishing notation." To me, as a native English speaker, "notation"sounds like something brief and might help keep people from wanting to write a paragraph of description. --Vasha (cazadora de tildes) 16:23, 28 August 2018 (EDT)
Hm, what about "Content disambiguation" or "Content/Disambiguation"? Label too long probably... Jens Hitspacebar 16:04, 28 August 2018 (EDT)
Why not just 'Disambiguation' (or 'Title disambiguation' - might be too long though)? Clear enough with a small bubble text explaining its use. And if you can do that, display Content if omnibus, display Disambiguation if not omnibus... MagicUnk 16:14, 28 August 2018 (EDT)
The technical term is disambiguator, but:
  • it's rather obscure, and
  • the people who are familiar with the term mostly know the computer science meaning: "a natural language processing application that tries to determine the intended meaning of a word or phrase by examining the linguistic context in which it is used", which is not what we are trying to do here
so I guess "disambiguator" wouldn't work too well. Something like "Disambiguation text", perhaps? Ahasuerus 21:38, 28 August 2018 (EDT)
I like "Disambiguation text" or even "Disambiguation note". Annie 01:08, 29 August 2018 (EDT)

Interior Art

Would we use this for interior art also? Instead of the current "(#)" for multiple illustrations in the same pub? -- JLaTondre (talk) 19:49, 28 August 2018 (EDT)

I assume that pretty much all disambiguation elements which are currently added to the "Title" field would be migrated to the new field. Ahasuerus 21:32, 28 August 2018 (EDT)

Excerpts

One area where the path forward seems to be reasonably clear is excerpts. If we add "excerpt" to the list of supported SHORTFICTION sub-types, we should be able to migrate 4,348 "(excerpt)" titles programmatically. It will leave us with the following breakdown of "(excerpt)" titles: 

+--------------+----------+
| CHAPBOOK     |        1 |
| ESSAY        |      118 |
| INTERIORART  |      150 |
| INTERVIEW    |        5 |
| NONFICTION   |        1 |
| POEM         |       55 |
| REVIEW       |        2 |
| SERIAL       |        2 |
+--------------+----------+

I don't think we'll be able to do much about them until we have some kind of disambiguator field added.

If there are no objections, I will create an FR for excerpts. Ahasuerus 16:56, 29 August 2018 (EDT)

This will actually solve the problem we have currently, where people have been using (excerpt) two ways: some people put that notation, or (excerpt from $Title), on any SHORTFICTION that's an excerpt; some only put it on excerpts whose title is the same as that of the larger work. I presume the new title type will correspond to the former usage. Good to have that ambiguity settled. And we will have to find unmarked excerpts and transfer them little by little by searching the notes. --Vasha (cazadora de tildes) 17:35, 29 August 2018 (EDT)
I also assume that it will apply to all fiction excerpts regardless of the title, but we will want to discuss the Help wording when the software changes are ready to be deployed. Ahasuerus 14:52, 30 August 2018 (EDT)
P.S. FR 1182 has been created. Ahasuerus 14:58, 30 August 2018 (EDT)

Title Disambiguators -- Tentative Outcome

It looks like we need to do a few things before we can tackle the larger issue of title disambiguators:

  • Address excerpts as per FR 1182
  • Add the ability to edit Title-specific fields during Pub Contents editing as per FR 1185

For now I have documented the problem and the proposed solution in FR 1186, "Create a Title disambiguator field". Ahasuerus 17:46, 5 September 2018 (EDT)

ISFDB Statistics page updated

The software that rebuilds the ISFDB Statistics page has been updated as follows:

  • missing record types (publishers, series, etc) have been added
  • all lists have been alphabetized
  • publisher/award/author directories have been hyperlinked

The new version of the page will become available overnight. Ahasuerus 17:39, 28 August 2018 (EDT)

ISFDB in Print

I just finished reading Jo Walton's An Informal History of the Hugos and the ISFDB is mentioned throughout the book as one of the tools that Walton and others used in researching her series of blog posts on the Hugos that were assembled for the book. Unfortunately, one of her mentions, in the entry on 1999, is a sort of backhanded compliment: "...every week it turns out to be worth dredging through the ISFDB's unintuitive interface...". I wonder what we could do to make our interface easier to use. When you're using it everyday, it's hard to see what might make things easier for more casual users. Still, it's heartening to see that our work here is useful to the larger community. --Ron ~ RtraceTalk 20:01, 28 August 2018 (EDT)

Maybe we could reach out to Walton to see what parts she found unintuitive? I can try contacting her. I've met her before. ···日本穣 · 投稿 · Talk to Nihonjoe 13:12, 29 August 2018 (EDT)
True, it can be hard to see the forest when you know every leaf on every branch of every tree. I guess we could start by asking Jo directly since her email address (bluejo@gmail.com) is public. Ahasuerus 13:16, 29 August 2018 (EDT)

Exterus Magazine

I just finished entering the first four issues of Exterus, which the editor considers a magazine. There is also a collection of stories from the first five issues which is called Exterus Omnibus. Some moderator has changed the entries for the first five issues of the magazine to ANTHOLOGY, and a corresponding EDITOR. The sixth issue has not been changed so far. Can someone tell me what is going on? I guess I don't care if for some reason someone thinks that anthology is more appropriate than magazine, but what's with the EDITOR? Bob 12:38, 29 August 2018 (EDT)

Looks like it's been changed back now. And I agree, it sure looks like a magazine to me. Let me point out, though, that if we're treating it as a magazine, we should enter the date as the cover date (year only if there is no month specified). --Vasha (cazadora de tildes) 13:04, 29 August 2018 (EDT)
Now I see where the ANTHOLOGY comes from. It's because it's identified as that in the Omnibus. It isn't possible to use MAGAZINE as an item of content in an OMNIBUS, so each edition of the magazine is labelled as an ANTHOLOGY. And by the way, there is no cover date on the magazines. There is a copyright year shown on the title pages. Should those be used? Bob 14:26, 29 August 2018 (EDT)
There are two titles for volume 5, one EDITOR and one ANTHOLOGY. I have tried merging them; let's see if that gets the EDITOR title into the omnibus. As both the date, yes, use the year on the copyright page. --Vasha (cazadora de tildes) 14:50, 29 August 2018 (EDT)
I am not familiar with Exterus, but magazine reprints are generally entered as separate ANTHOLOGY records, e.g. see this reprint series or this other reprint series. Ahasuerus 16:49, 29 August 2018 (EDT)
OK, that makes sense, thanks for the tip. Bob, can you figure out whether the contents of the "anthology" in the omnibus is actually the same as the magazine? Dirk just pointed out that they have significantly different page counts. And this is another case where disambiguation may be called for ... --Vasha (cazadora de tildes) 17:28, 29 August 2018 (EDT)
I think everything is now clear with the Exterus Omnibus now correctly identified as an ANTHOLOGY, so there is no need for embedding the titles of the individual magazines. As for page counts, I looked at the page counts of the magazines and the TP version of the Omnibus, and they were fine. But the pages in the ebook version of the Omnibus are longer than the pages in the TP. This is why it was possible to fit five additional stories in the ebook version without adding a bunch of pages. Bob 19:56, 31 August 2018 (EDT)

Seiun Awards finally current

The Seiun Awards are finally current. It took quite a while because I had to find where all the short stories (and translated short stories) were first published and enter that item with as much of the contents as I could find. Now I'm working on the Taisho Awards. These should go much faster as there are only 1-3 awards given out each year (usually just one). ···日本穣 · 投稿 · Talk to Nihonjoe 20:53, 29 August 2018 (EDT)

Thanks! One award at a time :-) Ahasuerus 21:01, 29 August 2018 (EDT)
And this one required extra work since all the translated works had to be matched up to the original works (not just in English!), as well as all the transliteration for every entry and every person and every series and every everything. It's too bad we don't have a way to enter transliteration for contents at the same time as for the container titles. ···日本穣 · 投稿 · Talk to Nihonjoe 21:04, 29 August 2018 (EDT)
That would be FR 959 :-) Ahasuerus 21:32, 29 August 2018 (EDT)
Any chance to nudge that one up a bit? Having to do 20 edits after I add an anthology with 10 stories in Bulgarian makes me just not add the books... :) Annie 18:19, 30 August 2018 (EDT)
I support this line of thought. It will make adding non-English magazines, collections, anthologies, and omnibuses much easier. ···日本穣 · 投稿 · Talk to Nihonjoe 19:13, 30 August 2018 (EDT)
For example: This, this, and this would have been entered much more quickly if transliterations for titles and authors could have been entered while creating the initial records. ···日本穣 · 投稿 · Talk to Nihonjoe 19:16, 30 August 2018 (EDT)
I am beginning to think that we need to create Roadmap 2018/2019. We are only half-way through Roadmap 2017, but so many other FRs have been created in the last 18 months that we may want to re-prioritize things. Ahasuerus 20:07, 30 August 2018 (EDT)
I support that. There have been quite a few new ones. ···日本穣 · 投稿 · Talk to Nihonjoe 20:52, 30 August 2018 (EDT)
Rereading the 2017 roadmap, there are three (four) FR's I'm particularly looking out for: record change history, translator field, multiple pricing, (and pub display order)... MagicUnk 02:05, 31 August 2018 (EDT)

Adding info to new titles -- a comprehensive solution?

There has been a bunch of grumbling about having to go back after having a magazine/anthology/etc. approved and add info to the stories in it. It has been proposed to add a field to the New Publication form after the titles for the new "disambiguation" field, for transliterations, etc. I'm thinking--instead of adding a few fields piecemeal, would it be possible to have a button next to the content title which would pop up a sub-form where you could enter everything about the title: transliteration, translator, series, notes, etc? --Vasha (cazadora de tildes) 16:53, 31 August 2018 (EDT)

Yes, it's possible, although I am not sure a pop-up window would be the best way to do it. When populating multiple fields and sub-fields, I find that it's better to have all of the entered data displayed on the same page. I typically try to re-check all data before submitting and it would be hard to do if some of it needed to be pulled up in separate sub-windows. I was thinking that small "+" buttons for "Disambiguation", "Transliterated Title", etc would work better: clicking them would add a new field to the title-specific section of the Content area just like "Add Author" adds a new Author field now. The software cleanup work that I wrapped up earlier this year should make adding this functionality easier. Ahasuerus 20:34, 31 August 2018 (EDT)
OK then -- in that case, a single + button "Add Field" with a dropdown list.--Vasha (cazadora de tildes) 06:42, 1 September 2018 (EDT)
Interesting. I hadn't considered a drop-down list. Thanks. Ahasuerus 21:29, 1 September 2018 (EDT)
FR 1185 has been created. Ahasuerus 16:36, 5 September 2018 (EDT)
However, there is another, larger, issue here. Our software is almost entirely hand-crafted. It worked OK 13-14 years ago when it was originally designed and implemented, but the world has changed since then. Almost everyone uses Web frameworks which facilitate building Web applications. They handle all kinds of things like security, HTML tables, etc, which lets developers concentrate on high level design. If we are going to continue to enhance the Content section, which is one of the more complex parts of our software, we may want to consider migrating to a Web framework. It will take a certain amount of time and effort at first, but eventually it should pay for itself. If we could find a developer with Web framework experience and pick his or her brain, it would be a good start. Ahasuerus 20:34, 31 August 2018 (EDT)
A complete rewrite of the software with a web framework would very likely make development easier in the long run, and, yes, it will certainly take a lot of time until it has the same amount of features the ISFDB has now. What I can say from my experience with web frameworks is: avoid JavaServer Faces. I've worked with it for a decade now and I'd ditch it (and the whole Java zoo) immediately if I had the chance to in favour of another, better one (though the framework and other parts of the zoo have improved over the years). On the other hand, the Ruby framework Ruby On Rails has so far been a very nice framework and much more joy to work with. It's Python counterpart Django might be a good choice for a potential ISFDB rewrite, but I have almost no experience with it. Django and Ruby On Rails are also well established web frameworks with many contributors, therefore a possible death of these projects (which would of course affect further development of your software) seems unlikely. Jens Hitspacebar 06:09, 1 September 2018 (EDT)
Thanks for sharing your experience! My hope is that even if we decide to implement a Web framework, we won't have to scrap and rewrite everything that has been done over the last 14 years. It retrospect, some of it, e.g. storing submissions as XML structures, may not have been optimal. However, redoing everything would require a lot more man-hours than we have, unless we get more active developers. In the meantime, perhaps it may be possible to leverage some existing third party libraries and frameworks to improve security and developer productivity. As we discussed a few weeks ago, they come with headaches of their own, but perhaps it would be a worthwhile trade-off. Ahasuerus 21:45, 1 September 2018 (EDT)

Shona added

The Shona language has been added to the list of supported languages. Ahasuerus 11:30, 5 September 2018 (EDT)

The Legend of the Ice People

According to Wikipedia, Margit Sandemo's 47-volume The Legend of the Ice People contains "some fantastical elements". Would anyone be interested in entering it? Ahasuerus 13:12, 6 September 2018 (EDT)

I added another 110+ volume series, so I can handle it. ···日本穣 · 投稿 · Talk to Nihonjoe 18:27, 9 September 2018 (EDT)
✓ Done. The Swedish Wikipedia lists it as a fantasy series. It's been added here. The author has also been updated. ···日本穣 · 投稿 · Talk to Nihonjoe 20:18, 9 September 2018 (EDT)
Thanks! Ahasuerus 20:52, 9 September 2018 (EDT)

Old Norse

I've come across a translation of a poem from Old Norse. Would it be possible to add it to our supported languages? Thanks. --Ron ~ RtraceTalk 09:41, 8 September 2018 (EDT)

Old Norse is an ISO 639-2-recognized language. I should be able to add it once I finish the weekly backups. Ahasuerus 10:35, 8 September 2018 (EDT)
Done! Ahasuerus 13:11, 8 September 2018 (EDT)
Thanks! --Ron ~ RtraceTalk 15:13, 8 September 2018 (EDT)

Infrequent languages: adding more?

I am thinking of entering Jalada Translation Issue 01, which is a fable by Ngũgĩ wa Thiong'o translated into more than 30 languages, mostly from Africa. The ones we don't already have are Gikuyu, Dholuo, Kikamba, Lwisukha-Lwidakho, Luganda, Ikinyarwanda, Meru, Lingala, IsiZulu, Igbo, Ibibio, isiNdebele, XiTsonga, Nandi, Rukiga, Bamanankan, Lugbarati, Lubukusu, Kimaragoli, Giriama, Sheng, Naija (Nigerian Pidgin), Dhopadhola/Adhola, Igala, Marakwet, Ewe, Setswana, Ebira, Sesotho, Kreol Morisien, Sepedi, Fombina, Kipsigis, Acholi, Tigrinya, Tigre, Dagaare, Ekegusii, Tamazight, Teso, Kannada, Odia, Kurdish, and Mixtec/Tu’un sávi. Also, the story appeared in Mandinka, Wolof, and Fula in another publication which I may be able to find information about.

Is it problematic to make the list of languages very long by including ones that have very few works published in them? Perhaps we could do like Goodreads does and have a separate section for frequently-used languages at the top of the list. --Vasha (cazadora de tildes) 12:49, 9 September 2018 (EDT)

I guess the first thing to do is to find these languages' ISO 639-2 names and codes. It's not always straightforward, e.g. "Gikuyu" is listed as "Kikuu/Gikuyu" and "Dholuo" is listed as "Luo" (see Wikipedia.)
If it turns out that some of them are not a part of the ISO 639-2 standard, then it will pose a different problem: we currently defer to ISO 639-2 for language identification and naming purposes. In the past we considered using ISO 639-3 instead, but it raised other questions like "who determines what is a language and what is a dialect?" In the end we decided to stick with ISO 639-2.
If we determine that ISO 639-2 has become too limiting for our purposes, we'll need to revisit the issue and pick the brains of our more language-savvy contributors. Ahasuerus 13:17, 9 September 2018 (EDT)
Indeed, some of these languages are only in ISO 639-3. Also, Sheng is not even recognized by Ethnologue and ISO because it is a cant (argot) -- I suppose you could just include it in Swahili as a variety of that language. --Vasha (cazadora de tildes) 14:12, 9 September 2018 (EDT)

African Languages - ISO names and codes

Language ISO Codes
ISO Name Name in Ruhlen Name in Jalada ISO 639-2 ISO 639-3
Acoli Acholi Acholi ach ach
Adhola Adhola Dhopadhola ssa [Nilo-Saharan languages] adh
Bambara Bambara Bamanankan bam bam
Bukusu/Lubukusu not mentioned Lubukusu bnt [Bantu languages] bxk
Chiga not mentioned Rukiga bnt [Bantu languages] cgg
Ebira Ebira Ebira nic [Niger-Kordofanian languages] igb
Ekegusii/Gusii Gusii Ekegusii bnt [Bantu languages] guz
Ewe Ewe Ewe ewe ewe
Fulah Fula Fula ful ful
Ganda Luganda Luganda lug lug
Giryama/Kigiryama Nyika Giriama bnt [Bantu languages] nyf
Ibibio Ibibio Ibibio nic [Niger-Kordofanian languages] ibb
Idakho-Isukha-Tiriki/Luidakho-Luisukha-Lutirichi not mentioned Lwisukha-Lwidakho bnt [Bantu languages] ida
Igala Igala Igala nic [Niger-Kordofanian languages] igl
Igbo Igbo Igbo ibo ibo
ISO 639-2: Kamba
ISO 639-3: Kamba (Kenya) 		Kamba Kikamba kam kam
Kannada Kannada Kannada kan kan
ISO 639-2: Kikuyu/Gikuyu
ISO 639-3: Gikuyu/Kikuyu 		Kikuyu Gikuyu kik kik
Kinyarwanda Rwanda Ikinyarwanda kin kin
Kipsigis Kipsikiis Kipsigis ssa [Nilo-Saharan languages] sgc
Kurdish Kurdish Kurdish kur kur
Logooli/Lulogooli Logoli Kimaragoli bnt [Bantu languages] rag
Lingala Lingala Lingala lin lin
Lugbara Logbara Lugbarati ssa [Nilo-Saharan languages] lgg
ISO 639-2: Luo (Kenya and Tanzania)
ISO 639-3: Dholuo/Luo (Kenya and Tanzania) 		Luo Dholuo luo luo
ISO 639-2: Mandingo
ISO 639-3: Mandinka 		Mandinka Mandinka man mnk
Markweeta Markweta Marakwet ssa [Nilo-Saharan languages] enb
Morisyen Kreol Morisien cpf [Creoles and pidgins, French-based] mfe
Meru Meru Meru bnt [Bantu languages] mer
[one of the Mixtec languages] Mixtec Tu'un sávi cai [Central American Indian languages] ???
Nandi Nandi Nandi niq niq
ISO 639-2: Fulah
ISO 639-3: Nigerian Fulfulde 		Fombina ful fuv
Nigerian Pidgin Naija Languej cpe [Creoles and pidgins, English-based] pcm
Northern Dagara Dagara Dagaare nic [Niger-Kordofanian languages] dgi
ISO 639-2: Oriya
ISO 639-3: Odia/Oriya (individual language) 		Oriya Odia ori ory
ISO 639-2: Pedi; Sepedi; Northern Sotho
ISO 639-3: Northern Sotho/Pedi/Sepedi 		Northern Sotho(?) Sepedi nso nso
Sheng [a Swahili argot] swa [Swahili]
South Ndebele R. does not distinguish
btwn N. & S. Ndebele 		isiNdebele nbl nbl
Southern Sotho Southern Sotho; Sesotho Sesotho sot sot
Standard Moroccan Tamazight Tamazight Tamazight zgh zgh
Teso Teso Teso ssa [Nilo-Saharan languages] teo
Tigre Tigre Tigre tig tig
Tigrinya Tigrinya Tigrinya tir tir
Tsonga Tsonga XiTsonga tso tso
Tswana Tswana Setswana tsn tsn
ISO 639-2: Wolof
ISO 639-3: Gambian Wolof 		Wolof Wolof wol wof
Zulu Zulu IsiZulu zul zul



Thanks for digging! I'll start working on adding the ISO 639-2 languages. In the meantime, I'll ask Linguist to stop by. Hopefully he can shed some light on the languages (dialects?) that are not in ISO 639-2. Ahasuerus 15:57, 9 September 2018 (EDT)

(unindent) Okay, so this is what I managed to find. The following ISO 639-3 tongues are entered as “languages” in the Greenberg (G) and Ruhlen (R) classifications (sources : Joseph H. Greenberg, Studies in African Linguistic Classification, Compass, Bradford, CT, 1955, 116 p.; Merritt Ruhlen, A Guide to the World’s Languages, Stanford University Press, Stanford, CA, 1991, 9th printing, 463 p.). I’m following the order of the chart above. The spelling is the one used in these sources.

  • Acholi (G, R).
  • Adhola (R).
  • Ebira (R).
  • Gusii (R).
  • Ibibio (R).
  • Igala (R).
  • Kipsikiis (R).
  • Logoli (R).
  • Mandinka (R) / Mandingo (G).
  • Markweta (R).
  • Meru (R).
  • Mixtec (R).
  • Oriya (R).
  • Teso (R).

Not recorded are :

  • Bukusu / Lubukusu.
  • Chiga / Rukiga.
  • Giryama / Kigiryama.
  • Idakho-Isukha-Tiriki / Luidakho-Luisukha-Lutirichi / Lwisukha-Lwidakho.
  • Lugbara / Lugbarati.
  • Mauritian Creole / Kreol Morisien.
  • Nigerian Fulfulde / Fombina.
  • Nigerian Pidgin / Naija Languej.
  • Northern Dagara / Dagaare.
  • Sheng.

In that lot, Mauritian Creole / Kreol Morisien is a variant of Réunion Creole, itself a variety of French Creole, which has a “language” status (not in the db, as far as I know; might be useful, as there is some literature in that language (there are “Tintin” and “Astérix” albums in Réunion Creole). Nigerian Fulfulde / Fombina is a Fulani dialect. As far as Nigerian Pidgin / Naija Languej is concerned, English Pidgin seems to be missing in the db, and there could easily be room for a general "English Pidgins". Northern Dagara / Dagaare is a Dagara dialect. Sheng must be assimilated to Swahili (a slang is not a language in its own right). I'll have to dig a bit more to have a clear view of the remaining five. Linguist 10:54, 11 September 2018 (EDT).

Thanks for looking into this! Ahasuerus 12:23, 11 September 2018 (EDT)
It would sure be nice if ISO had a code covering all 3 Dagaare languages but it doesn't. If we want to add Dagaare at all we'll have to add 3 codes which could be called something like "Dagaare (Northern)," "Dagaare (Southern)" and "Dagaare Dioula." The thing is that ISO 369-3 is a work in progress. We might just have to commit to keeping an eye on it and adjusting our list when we can, if for example they add a macrolanguage code for Dagaare. --Vasha (cazadora de tildes) 12:19, 11 September 2018 (EDT)

Language names

P.S. We'll also need to decide which names we want to use. Some ISO names, e.g. "Northern Sotho/Pedi/Sepedi", are on the long side. Ahasuerus 16:07, 9 September 2018 (EDT)

As far as language denominations are concerned, as we are an English-language db, we'd better stick to the usual English names of the ISO 639-2-recognized languages in question, and forget about local usage. After all, we don't use français for French or deutsch for German. As for the language / dialect distinction, for many reasons, linguists usually consider this a highly subjective point of view, with strong political and nationalistic overtones (e.g. Galician is historically a variety of Portuguese, but has long been included in Spanish dialects, etc.). Linguist 09:29, 10 September 2018 (EDT).
That was one of the reasons why we farmed it out to ISO 639-2 in the first place :) Ahasuerus 11:25, 10 September 2018 (EDT)
I'll do what I can with the ISO 639-3 African languages, but I need to check a few things first. I'll keep you informed… :o). Linguist 09:29, 10 September 2018 (EDT).
Thanks!
Re: the issue of naming, I agree that we want to use their English names, but the problem is that sometimes the ISO standard lists multiple alternative names. For example, take Asturian. The 639-2 standard calls it "Asturian; Bable; Leonese; Asturleonese". After some hesitation, we decided to call it "Asturian/Bable". I wonder if it would be feasible to do similar pruning with certain ISO language names like "Northern Sotho/Pedi/Sepedi". Ahasuerus 11:25, 10 September 2018 (EDT)
It may be best not to use the ISO standard as the source of names since their practices may differ from familiar colloquial names for the language. The Sotho languages are a good example; I've been doing some Internet searching and what I find is that absolutely no one uses the names Northern Sotho and Southern Sotho except linguists. The official South Africa names are Sepedi and Sotho; colloquial practice is to call the first Sepedi and the second either Sesotho or Sotho. I think we should not use linguists' names here; experts are capable of finding variant names. So my suggestion for our two names would be "Sepedi" and "Sesotho/Sotho." --Vasha (cazadora de tildes) 04:43, 11 September 2018 (EDT)
The problem with abandoning one part of the ISO standard is that we may be opening cans of worms that we are not even aware of. Country/language names can be controversial, e.g. "Ukraine" vs. "the Ukraine" before the name was officially changed. Who knows what kind of baggage the names of less popular languages may carry? By using an international standard approved and maintained by a third party, we avoid all of these issues. Ahasuerus 11:00, 11 September 2018 (EDT)
We do casual searchers a disservice by using ISO names that they're not familiar with, and being able to say "If we used a wrong name, blame ISO not us" is not sufficient justification. The task of researching what native speakers call their language when speaking English, while difficult, is not impossible, I think. --Vasha (cazadora de tildes) 12:28, 11 September 2018 (EDT)
It may be possible, but I don't think it would help us. As discussed earlier, we use English names as opposed to français, deutsch, nederlands, srpski, polski, nihongo, etc. Ahasuerus 12:52, 11 September 2018 (EDT)
P.S. Sorry, I missed the "when speaking English" part. Ahasuerus 13:09, 11 September 2018 (EDT)
Easier is simply finding out the most widespread appellation. --Vasha (cazadora de tildes) 12:28, 11 September 2018 (EDT)
The issue here is that the "most widespread appellation" may be different depending on the period, the region and the subset of literature that you check. The Ukrainian controversy that I mentioned earlier is a perfect example: prior to 1991 you would have gotten different results depending on which books you had access to. Historians had to add notes explaining why they went with one usage or the other. Etc.
It was exactly what we were trying to sidestep when we decided to farm these decisions out to a professional organization like ISO -- they are vastly better qualified to make these types of decisions than we will ever be. I can see us using another third party source (like the ones consulted by Linguist yesterday), but I believe that it would need to be an established professional/neutral source at the level of ISO as opposed to our own research. Ahasuerus 13:08, 11 September 2018 (EDT)
A good idea in principle, but ISO ISO is not user-friendly for laypeople. Isn't there a better third parry to call on? (Wikipedia?) --Vasha (cazadora de tildes) 14:23, 11 September 2018 (EDT)
I think ISO 639-2, which covers major languages, has served us well overall. ISO 639-3, which was expanded to cover less popular languages and dialects, may be more problematic. Unfortunately, I don't know enough about the field to suggest other sources which we may be able to use either as an alternative to ISO 639-3 or in conjunction with it. Perhaps we can use Merritt Ruhlen's 1991 A Guide to the World’s Languages -- see Linguist's post below -- to define the subset of ISO 639-3 languages which we want to support.
Wikipedia, alas, is too transient for our purposes. Back when it became big (ca. 2005-2006), Al and I thought that we could move certain types of ISFDB data there and then link to it. That's why the original ISFDB 2.0 design supported only one Web page per record and it was reserved for Wikipedia URLs. Unfortunately, after writing lots of SF and other articles for Wikipedia, I realized that Wikipedia was unlikely to become as reliable or as permanent as we had hoped. That's when I converted the "Wikipedia URL" field to a "multi-field" for third party Web pages and Wikipedia lost its privileged position. Ahasuerus 15:03, 11 September 2018 (EDT)

(unindent) Would you suggest that we use Greenberg and/or Ruhlen as the guide when deciding which ISO 639-3 languages to include? I suppose Ruhlen would be a better choice because it covers the whole planet and because it's much more recent. Also, have there been updates since 1991? I am thinking of things like the official split of the "Serbo-Croatian" language into Serbian and Croatian, which was reflected in ISO 639-2 (and consequently in our software.) Are there similar issues with ISO 639-3-only languages which have arisen since 1991? If there are, we'll need a way to handle them. Ahasuerus 12:23, 11 September 2018 (EDT)

Yes, I think following Ruhlen would be a good choice — although of course he is not the only reference in that matter, but he is one of the most recent ones. As far as I know, there have been reprints but no new editions of his Guide to the World’s Languages (contrary to his Guide to the Languages of the World, 1975, new expanded edition 2005, but mainly concerned with phonological systems). I can't think of any major issues with ISO 639-3-only languages at the moment, but if I come across them I'll let you know. Linguist 11:18, 12 September 2018 (EDT).
Thanks! Re: creoles and pidgins, ISO 639-2 has a special code, "crp", explicitly for "Creoles and pidgins". Would it be helpful to add it? Ahasuerus 21:54, 12 September 2018 (EDT)
Personally, I find it a bit too general. Would it be possible to have something like English-based Pidgin, French-based Creole, etc. ? To be created as you need them, not to clutter up the list too much… Linguist 08:01, 13 September 2018 (EDT).
It turns out that ISO 639-2 has separate codes for "Creoles and pidgins, English based", "Creoles and pidgins, French-based", and "Creoles and pidgins, Portuguese-based" as well as a cat-all code for "Creoles and pidgins". Problem solved! :-) Ahasuerus 20:54, 18 September 2018 (EDT)
One problem is that the debate as to whether Nigerian Pidgin is a pidgin or a creole is currently unresolved. --Vasha (cazadora de tildes) 12:20, 13 September 2018 (EDT)

ISO 639-2 vs. ISO 639-3 vs. Other Nomenclatures

Re: ISO 639-2 vs. ISO 639-3, it's a thorny issue. ISO 639-2, which we currently use, may have become too restrictive now that we are beginning to enter less well-known languages. For example, ISO 639-2 has individual codes for some more popular Bantu languages, but the rest are covered by "bnt", a catch-all code for all Bantu languages and dialects. That doesn't given us enough granularity when trying to enter an anthology of stories written in different Bantu languages.

On the other hand, ISO 639-3 may have more granularity than we need. For example, it states that Albanian is a macrolanguage and lists 4 "individual languages" under it: "Arbëreshë Albanian", "Arvanitika Albanian", "Gheg Albanian" and "Tosk Albanian". I am sure it's a useful distinction when dealing with the spoken language, but not one that we would want to use for bibliographic purposes since, as far as I know, the written language is just "Albanian".

So... If ISO 639-2 is "too little" and ISO 639-3 is "too much", what should we do? I guess what we are after is the "literary" subset of ISO 639-3 codes. Does such a thing exist? Ahasuerus 11:25, 10 September 2018 (EDT)

I am coming around to thinking that it might be OK to stick with using ISO 369-2 on condition that:
  1. we identify some groups of languages that can be covered by a common ISO 369-2 code, and use Ruhlen's name for the group, with details of the exact language to be given in the title notes;
  2. we use Ruhlen's names for individual languages that have ISO 369-2 codes;
  3. we add a category "Other" (or "Other [see notes]") for languages that aren't accommodated by either of these.
The upside is a shorter, simpler list of languages; the downside is that someone who (for example) wonders whether any speculative literature has been published in Mixtec would have to search the notes rather than the list of languages. --Vasha (cazadora de tildes) 13:21, 12 September 2018 (EDT)
"Other" is an interesting idea. It's not explicitly in the ISO 639-2 standard, but ISO 639-2 includes a range of codes (qaa-qtz) which are officially "reserved for local use". If we add "Other" as a "local use" language, we won't be going against the standard. The only possible caveat that comes to mind is that we will need to decide how to enter certain uncommon dialects. For example, is the famous Cockney rhyming slang "English" or "Other"? Not that I expect many SF stories written using Cockney, but you never know.
Re: the use of Ruhlen's language names, let me make sure that I understand the proposal correctly. Are you suggesting that when ISO 639-2 and Ruhlen's book use different language names, we should use Ruhlen's name instead of what's listed by ISO 639-2?
If so, how about a compromise: we take the ISO 639-2 name as well as Ruhlen's name and create a composite name like "Asturian/Bable" or "Pashto/Pushto"? Ahasuerus 22:25, 12 September 2018 (EDT)
I guess it does no harm to put a long string of alternate names in the list. The important thing would be to put the most familiar-to-laypeople name first, for the sake of people who are using the list by scrolling rather than typing. --Vasha (cazadora de tildes) 22:46, 12 September 2018 (EDT)
I can think of three categories of users who would be affected by the displayed order of language names:
  1. Users who view titles
  2. Users who select languages in Advanced Search
  3. Editors who edit data
For the first category of users, the order of language names shouldn't matter much because all of them would be displayed on the same line. For the second category of users, the impact would be more significant. For the third category of users, I suspect that the impact may be less significant than in the second case because data entry work is more time-consuming than casual searching, so editors become more accustomed to the way the software works. Am I missing any other categories? Ahasuerus 13:16, 13 September 2018 (EDT)
We could also enhance the drop-down lists to search for any string contained in the list, not just the first few letters. Ahasuerus 22:25, 12 September 2018 (EDT)
I'm not sure about your proposed modification to the typing; wouldn't it throw people off to type "fr" like they're accustomed to and instead of the French they want, get Afrikaans? --Vasha (cazadora de tildes) 22:46, 12 September 2018 (EDT)
That's a good point. I failed to consider the side effects. I wonder if there may be another way to allow searching for language names without affecting the established process. Ahasuerus 12:55, 13 September 2018 (EDT)
Have advanced search be free text rather than the list; keep established behavior otherwise. --Vasha (cazadora de tildes) 13:56, 13 September 2018 (EDT)
An interesting thought. I can see how it could be useful even when looking for certain languages that we currently support, e.g. Serbo-Croatian/Serbian/Croatian and the three forms of Norwegian.
On the other hand, it's handy to be able to scroll through the list of supported languages, which can serve as a discovery tool: "Oh, there is SF written in Ancient Greek and Latin? Let me see..." It can also help with pesky spelling problems, e.g. is Yiddish spelled "Yiddish" or "Yidish" in English?
So how about we try to have our cake and eat it too? Instead of changing the current Advanced Search option why don't we rename it to something like "Language (list)" and add a new option to the left column, "Language (free form)"? Ahasuerus 16:02, 13 September 2018 (EDT)

Handling Languages in the Software

Just a thought here: How many stories will we have from these languages? Adding them is all good and nice until you need to work with that list and it takes 2 minutes to get to the language you need. If we are going to keep adding languages, we need the ability to have "shorter" list in some way or form (globally or as a profile setting)...Annie 18:11, 9 September 2018 (EDT)

I like this idea. If there was a way to "subscribe" to languages, perhaps they could be listed at the top of the drop-down, before all the other languages (as a user setting). ···日本穣 · 投稿 · Talk to Nihonjoe 18:26, 9 September 2018 (EDT)
Nihonjoe's idea isn't a bad one. On the other hand, I could envision where a pulldown menu has a short(ish) list and the last first item on the list is "show extended list" which, when clicked, expands the rest. (ETA: I don't think this works; more pondering needed.) Here's the languages which we currently have at least 40 titles in, with parentheses marking ones which would be excluded by a cutoff at 50 titles: (Ancient Greek), (Arabic), Bulgarian, Catalan, Chinese, Croatian, Czech, Danish, Dutch, Esperanto, Finnish, French, German, Greek, (Hebrew), Hungarian, (Icelandic), (Irish), Italian, Japanese, Korean, Latin, Lithuanian, Norwegian-Bokmal, Polish, Portuguese, Romanian, Russian, Serbian, Slovenian, Spanish, Swedish, Turkish, Yiddish. --Vasha (cazadora de tildes) 19:00, 9 September 2018 (EDT)
When I pull up the language list, I simply type "fr" for French, "ger" for German, etc, which lets me jump to the right language almost instantly. Do other editors use different methods? Ahasuerus 19:18, 9 September 2018 (EDT)
I do that too on a laptop/desktop. Unfortunately, it isn't possible on a mobile interface. --Vasha (cazadora de tildes) 19:23, 9 September 2018 (EDT)
Oh, mobile devices. I see. Ahasuerus 20:53, 9 September 2018 (EDT)
It occurs to me, also, that language is one thing that casual searchers are likely to want to search by. A solution to make the list more manageable for them shouldn't depend on user preferences. --Vasha (cazadora de tildes) 19:38, 9 September 2018 (EDT)

(unindent) I wonder if the ideal solution may not be some kind of combination of the two proposed approaches. Something like:

  • Create a nightly process to identify the top 10 most popular languages
  • Change the drop-down lists of languages to display an alphabetized listing of the "top 10" at the beginning of the list (make sure that it is displayed as a separate sub-section)
  • Let users override the "top 10" list with whatever they want

It wouldn't be hard to do conceptually, just somewhat time-consuming to implement. Ahasuerus 22:25, 9 September 2018 (EDT)

The top 7 would be sufficient; there is a pretty obvious gap between them and the rest. --Vasha (cazadora de tildes) 18:02, 13 September 2018 (EDT)

"Other" vs. ISO 639-2 language groups

Re: the issue of non-ISO 639-2 languages, the use of "other" has been suggested. However, as we discussed earlier, it would cover a lot of different unrelated languages.

After sleeping on it, I think we may be better off using ISO 639-2-supported language groups whenever possible. For example, the Teso (Ateso) language doesn't have an ISO 639-2 code, but ISO 639-2 has a code for "Nilo-Saharan languages" languages. Similarly, ISO 639-2 doesn't have a code for the Chiga/Rukiga/Kiga language, but it has a code for "Bantu languages". Etc.

It seems like it would give us a lot more granularity than "other" and would make our users' life easier. Ahasuerus 20:06, 14 September 2018 (EDT)

Yeah, not a bad idea. I hope it'll be possible to find suitable super-categories for all the languages we need. On a more detail-oriented note, I think the entry in the list should be "Bantu language" or "Nilo-Saharan language," with the capitalization as shown so as to indicate that this is not the name of an individual language. --Vasha (cazadora de tildes) 20:35, 14 September 2018 (EDT)

Trying to Formulate Tentative Consensus

Re-reading the discussion above, I think we are getting close to something approximating a tentative consensus re: a few issues. Here is what I think we can agree on at this point:

  • In Advanced Title Search and Advanced Author Search, rename the "Title/Working Language" field to "Title/Working Language (list)". Add a new option, "Title/Working Language (free form)".
  • For ISO 639-2 languages, check Merritt Ruhlen's A Guide to the World’s Languages (Stanford University Press, Stanford, CA, 1991, 9th printing) to see if the latter uses a different language name. If it does, append add it to the ISO 639-2 language name.

Does this look right? Ahasuerus 20:06, 14 September 2018 (EDT)

You mean "add it to ..." instead of "append it to ..." right? :-) We are still arguing the issue of how to determine which name goes first --Vasha (cazadora de tildes) 20:12, 14 September 2018 (EDT)
Sorry, I thought the issue lost its relevance when the Advanced Search change was proposed. Let me change "append" to "add" to leave it open-ended. Ahasuerus 23:37, 14 September 2018 (EDT)
Well, the proposal is to have a list in Advanced Search as well as freeform search. So, if one name for a language is used significantly more often than others, putting it first maximizes the chance of someone scrolling down the list spotting what they're looking for. --Vasha (cazadora de tildes) 12:11, 15 September 2018 (EDT)

(unindent) I haven't forgotten about this issue. I am currently working on something else and hope to wrap it up in the next day or two. I will then revisit this area. Ahasuerus 10:46, 16 September 2018 (EDT)

The table has been updated with Ruhlen's names and ISO 639-2 codes for language families. I have asked Linguist to review the results to make sure that I didn't mess up any assignments.
Assuming there are no changes, there is only one ISO 639-2 language whose ISO 639-2 name differs from the name used by Ruhlen: "Acoli" (ISO 639-2) vs. "Acholi" (Ruhlen). Given that it's just one language and that the difference is minor and doens't affect sorting, I don't think adding Ruhlen to our mix of standards would be worth it. Ahasuerus 21:11, 18 September 2018 (EDT)
I have added some more info to the table. I found that Mandinka does indeed have an ISO 639-2 code "man" (under the less-used name Mandingo), and also I found some codes where we'll need to make choices about what names to use in what order:
  1. Minor differences: ach (Acoli, Acholi); ful (Fulah, Fula)
  2. Greater differences: kin (Kinyarwanda, Rwanda); lug (Lugbara, Logbara); luo (Luo, Dholuo)
  3. Potentially especially confusing: sot (Southern Sotho, Sotho, Sesotho); nso (Northern Sotho, Sepedi, Pedi). Also nde & nbl (North[ern] and South[ern] Ndebele) since they are not necessarily distinguished from one another; according to Ethnologue they use the same autonym.
In the second and third groups, further research into colloquial and official names is required. --Vasha (cazadora de tildes) 20:30, 20 September 2018 (EDT)
Thanks for digging! While we are waiting for Linguist to review the findings, I plan to go ahead and add the ISO 639-2 languages which do not have a conflict. I can't think of any reason to keep Kurdish or "Creoles and pidgins, French-based" out while we are sorting out various versions of Sotho, Ndebele, etc. Ahasuerus 13:16, 24 September 2018 (EDT)
ISO Code Names with Approximate GHits Suggested Name
ach Acoli Acholi Acholi
30 1700
ful Fulah Fula Fula
50 11,000
kam Kamba Kikamba Kikamba (text searches
for Kamba will find this)
450 400
kik Kikuyu Gikuyu Kikuyu/Gikuyu
17,500 800
kin Kinyarwanda Rwanda Kinyarwanda
18,000 3,000
lug Ganda Luganda Luganda
250 17,000
luo Luo Dholuo Luo/Dholuo
8,600 3,400
man Mandingo Mandinka Mandinka/Mandingo
1,700 2,900
nso Northern Sotho Pedi Sepedi Sepedi/Northern Sotho
4,200 250 38,000
ori Oriya Odia Odia/Oriya
33,000 51,000
sot Southern Sotho Sotho Sesotho Sesotho/Southern Sotho
800 10,600 30,000

Also, I suggest that the best way of resolving the Ndebele problem might be nde = "Ndebele, Northern (Zimbabwe)"; nbl = "Ndebele, Southern (South Africa)" --Vasha (cazadora de tildes) 20:00, 28 September 2018 (EDT)

As I mentioned earlier, I am not a fan of using internet search results for these purposes. Country/language names can have a ton of baggage which we may not be familiar with and are certainly not in a position to take a stand on -- see "Kampuchea/Cambodia", "Ukraine/the Ukraine", "Serbian and Croatian vs. Serbo-Croatian" pre-1991, etc. I can see us changing our standard to allow appending names used by a reputable third party, but not the internet. Ahasuerus 19:01, 29 September 2018 (EDT)
Did you have a chance to check out the results of my internet rsearch above? Mostly the results don't conflict with ISO-approved names, they only tell us which order we should list the names in. (And if you insist on using ISO's spelling "Fulah" in spite of the fact that absolutely no one else does, no real harm done.) There is, however, one real problem, namely Ganda/Luganda. The ISO-aproved name "Ganda" comes up only 250 times in searches for everyday uses verses 17 thousand hits for "Luganda." If we listed only the ISO name "Ganda", people looking for "Luganda" would not be able to find it either in the alphabetical list or by text searching. Seems like we absolutely must disagree with ISO here. --Vasha (cazadora de tildes) 19:04, 29 September 2018 (EDT)
Yes, I was responding above while you were writing this comment.
I should probably add that my concern is not purely hypothetical. A few years ago a new editor joined and wanted to eliminate a certain language. A bit later another editor joined and began using that very language, so there was clear potential for conflict. At the time we were able to avoid the problem by pointing out that the language was a part of ISO 639-2. That was a very convincing argument in favor of sticking to ISO 639-2 as much as possible.
In any event, the good news is that the experiment with changing "Mayan languages" to "Mayan language" was a success. Back when languages were added, I didn't consider the possibility that language names may need to be changed, so the software wasn't designed to support the functionality. Now that we know that it can be done and that the only downside is that old submissions will continue to display the old language name, it makes things much easier. We can add the ISO 639-2 names to the system, enter the titles that require them and then debate whether we want to change our standard for language names. Ahasuerus 13:28, 30 September 2018 (EDT)
I do not mean search results to be authoritative, only to give hints as to how to most helpfully use names. And for matters that will hardly affect user experience, such as the spelling of Acholi/Acoli, I have no problem going with ISO. But this quick search does flag up some issues that deserve to be further examined.
Almost all of the names I searched are used in ISO 369-3. You do not object to adding ISO 369-3's "Mandinka" to ISO 369-2's "Mandingo," do you? Ditto for "Dholuo" and "Odia." As I said, in most cases I want to use these search results as a hint of what order to put the names in -- it is useful information when there is a very glaring difference between the two names. And the results for Luganda ("Ganda" used only 1.5% of the time!) tells us that yes, we need to look to another source there. (Ruhlen uses "Luganda.") --Vasha (cazadora de tildes) 15:42, 30 September 2018 (EDT)
The problem with using ISO 639-3 names is that some of them may describe different languages. For example, the "Oriya" recognized by ISO 639-2 (ISO code "ori") is a macrolanguage; ISO 639-3 calls it "Oriya (macrolanguage)". On the other hand, "Odia/Oriya" (ISO code "ory"), which is recognized by ISO 639-3 but not by ISO 639-2, is an individual language. That's why ISO 639-3 calls it "Odia, Oriya (individual language)". So if we were to add "Odia" to the name "Oriya", we would be effectively adding a language not recognized by ISO 639-2. It's a jungle out there... Ahasuerus 19:17, 1 October 2018 (EDT)
Yes, I see. And I now notice that Mandingo (man) according to Ethnologue is a macrolanguage which includes Mandinka (mnk). Ugh. Well, I guess this isn't all that different from using names of language groups--you just have to explain in notes exactly what language is meant. At least Dholuo is a genuine alternate name of Luo according to Ethnologue; could we call that one "Luo/Dholuo" so that if anyone searches for "Dholuo" they can find it? And Ethnologue prefers the name Ganda but does admit luGanda (capitalized thus) as a genuine alternate name. --Vasha (cazadora de tildes) 19:37, 1 October 2018 (EDT)

Statistical reports migrated to the nightly job

The process of generating ISFDB Statistics and Top Lists has been migrated to the nightly job, which should improve performance. No more waiting 5 seconds for the software to generate a list of the Highest Ranked Titles of All Time etc. A few reports may still take a second or so to compile, but overall performance should be much better than under the old system.

As a general observation, it's unfortunate that performance tweaks consume valuable development man-hours. However, it's an inevitable side effect of database growth: the same reports that took a second to compile in 2012 may take up to 5 seconds to compile in 2018 because we have many more records on file: 54,775 awards, 1,519,153 titles and so on. It requires rethinking and rewriting certain parts of our software which I'd much rather leave alone, but c'est la vie. Ahasuerus 17:01, 11 September 2018 (EDT)

Audible.co.jp ASINs

I just entered this one. It's an audiobook on Audible.co.jp. Using the Audible ASIN opton doesn't work because it defaults to the US store. Do we want to add support for Audible.co.jp? They don't have much there yet, but it seems to be growing. Here's the SF/Fantasy category. ···日本穣 · 投稿 · Talk to Nihonjoe 20:24, 11 September 2018 (EDT)

Let's think about it. Regular ASINs are supposed to be unique across all Amazon stores. For example, the ASIN of this publication is B00TONTAEQ. Our publication record displays ASIN-based links to the 14 supported Amazon stores. With one exception (not available in Canada for some reason) they all take you to the right ebook at the right store.
Are Audible ASINs also unique across all Amazon stores? If they are, I can easily make Audible ASINs behave like regular ASINs and display links to the supported Amazon stores. Ahasuerus 21:10, 11 September 2018 (EDT)
I'm pretty sure they are. They just don't show up in the US Audible store when you go there. Now we just need a list of all the Audible stores. ···日本穣 · 投稿 · Talk to Nihonjoe 21:17, 11 September 2018 (EDT)
It would be nice to review an example of an Audible ASIN being used across multiple Audible stores. As I recall, Annie worked on Audible books at one point. Perhaps she may have additional insight into this issue. Ahasuerus 22:41, 11 September 2018 (EDT)
I doubt that there will a lot of cross publication between Japanese and English titles but the US store had been adding some more international titles lately so I willl see if I can figure out something when I get to a real computer tomorrow. From what I saw on the Japanese site, these look like regular B ASINs which Amazon has only one data add of. But will do some more digging and checking to see if I can spot a ASIN used at 2 ormore audible sites. Annie 01:05, 12 September 2018 (EDT)

Third party URL validation tweaked

Third party URL validation has been further tweaked. In addition to angle brackets, spaces and double quotes are no longer allowed. There are a few dozen bad URLs in the database (some are not clickable), which I will be fixing manually. Ahasuerus 17:46, 12 September 2018 (EDT)

Done. Ahasuerus 15:10, 13 September 2018 (EDT)

Cover art field in publication view

I just noticed: There is now no need to have the label "Cover" be a link to the cover art record in publication view, since we changed to having the title displayed there --Vasha (cazadora de tildes) 05:47, 13 September 2018 (EDT)

Well spotted. Fixed. Ahasuerus 15:48, 13 September 2018 (EDT)

External ID cleanup and validation

Earlier today I discovered that the External ID field was used incorrectly in certain cases. Some editors occasionally added parenthetical notes, which broke automatically generated links to third party sites. There were also pubs with cover artists, authors or series names in the External ID field, apparently due to data entry errors.

I have cleaned up the data and updated the software to disallow the same set of invalid characters that is currently disallowed for third party URLs: spaces, double quotes and angle brackets. The software changes were a bit trickier than I originally expected; if you come across anything unexpected, please let me know. Ahasuerus 18:51, 14 September 2018 (EDT)

Expand the "Tr" template with an author ID so that it can create a link to existing author records

I've been going through some title records which don't contain the {{Tr}} template, but do contain "Translated by X" text in the note, in order to replace it with the "Tr" template. It looks like many of these translator information have been entered with a link (<a href tag) around the translator's name if the translator already has an author record in the database (example). The only way to keep the link is either to put the "Tr" template inside the a href tag (example), or to include the complete a href tag inside the "Tr" parameter. I think we could make adding the link manually superfluous because the template itself could create the link: the software could add the possibility to additionally state the author id, for example in this way: {{Tr|X|id}}. This would also show "Translated by X", but the "X" would be a link to the author record of the provided id. Jens Hitspacebar 10:57, 16 September 2018 (EDT)

Adding record IDs to templates (any templates, really) would not be safe since our IDs are not guaranteed to be stable.
However, since the "A" template already links to author records based on the entered name, it would be easy to modify the "Tr" template to do the same thing. We'll just have to flesh out the error message which the Summary page displays. Instead of "Author not found: [name]" it could say something like "No works attributed to [name] on file". Ahasuerus 11:33, 16 September 2018 (EDT)
Hm, good point. Your suggestion would always add a link, if I've understood it correctly. I'm not sure if that's a desirable feature, considering that many translators don't have an author record in the database yet, and also considering that the parameter in the "Tr" template has been used for multiple translators in forms like "{{Tr|Translator 1, Translator 2 and Translator 3}}" already. Always having a link would probably create more "Not found" events for users than leading them to a real author record. Reconsidering all this I think the small benefit of such a feature is not worthwhile the hassle it may bring, and I rather withdraw my suggestion :) Jens Hitspacebar 12:28, 16 September 2018 (EDT)
Thinking some more about it, it occurs to me that we could create a new, linking, template for translators who are also authors. It would be easy to implement, although I am not sure how useful it would be. Ahasuerus 12:48, 16 September 2018 (EDT)
Assuming you can't embed templates e.g. "{{Tr|{{A|Translator}}}}", we could put "{{Tr|Translator}} (see {{A|Translator}}}". ../Doug H 13:30, 16 September 2018 (EDT)
A new, linking template would work, but then we'd have two similar templates to teach to editors and to keep track of in software and wiki changes. Not sure if it's worth the effort. Though I'd use it if it existed. :) Jens Hitspacebar 13:43, 16 September 2018 (EDT)
Then there's the issue of variant names. Some translations by authors who have records in this database are credited using names or forms thereof that we do not have pseudonym records for. So they wouldn't link correctly. Plus, translations credited to names that are disambiguated surely haven't been correctly dealt with. So yeah, we would need a new template rather than changing the old one, and it would have to have some way of both indicating how the translator is credited in the book, and what their canonical name is. It'd be nice to have the info available when we finally have a real translator solution in place, but I'm not sure it's worth putting a lot of work into at this stage. --Vasha (cazadora de tildes) 18:41, 16 September 2018 (EDT)

New cleanup report -- anthologies and collections without fiction titles

A new cleanup report, Anthologies and Collections without Fiction Titles, has been deployed. The data will become available tomorrow morning. Here is how FR 1164 describes the new functionality:

  • Create a cleanup report to find anthology and collection publications with no fiction titles. It should consist of 2 Web pages.
  • The first Web page will contain 2 tables. The first table will show counts of empty pubs per year and per month since 2000. The second table will show counts of empty pubs per decade and per year prior to 2000. Each count will be a link to the second Web page, which will display a standard table of eligible pubs. The first page will also contain a separate link for 0000-00-00 pubs.
  • The second Web page will display each empty pub's title, author, date, title type and note. Moderators will be able to ignore pubs.

Once we confirm that everything is working as intended and that the design is solid, we can create a similar report for magazines and fanzines. At some point, once the cleanup process has reached the point of diminishing returns, we can change these reports to include publications with only one fiction title. Ahasuerus 13:41, 17 September 2018 (EDT)

The following changes have been made to the second page of the cleanup report:
  • The "Pub. Type" is now called "Type". Its values are displayed as "COLL" and "ANTH".
  • A new column, "Publisher", has been added.
  • A new column, "1st Edition", has been added. It displays the date of the container title if it differs from the date of the publication.
Ahasuerus 16:30, 24 September 2018 (EDT)
I like it. The inclusion of the 1st edition column + the Notes really helps for spotting ones I want to fill in. (Yeah, yeah, they should all be filled in, but be real, there aren't three of me.) --Vasha (cazadora de tildes) 17:11, 24 September 2018 (EDT)
Thanks for working on these issues! Ahasuerus 18:11, 24 September 2018 (EDT)

Advanced Search - free-form language searches

Advanced Title Search and Advanced Author Search have been enhanced. You can now choose either "[Title/Working] Language (list)" or "[Title/Working] Language (free form)" from the drop-down list. The "(list)" version supports the same functionality as the previous language search version. The "(free form)" version lets you enter an arbitrary string of characters in the search value field. Ahasuerus 12:25, 18 September 2018 (EDT)

Pauline Morgan canonical name

This author uses the name Pauline Morgan for all of her editorial and reviewing work, and the name Pauline E. Dungate for all of her fiction. Is there some reason why we have Morgan as the canonical name? Wouldn't it be more usual to go with the one she uses for fiction writing instead? --Vasha (cazadora de tildes) 06:02, 21 September 2018 (EDT)

Do you know the author's legal name? In cases like this for me it seems most rewarding to use the legal name as canonical (so we would show the pseudonym as pseudonym, and not the legal name; however, there are many cases where the pseudonym is used far more exceedingly for the majority of an author's work). Stonecreek 08:29, 21 September 2018 (EDT)
Well, the standard is the most recognized name for that author within the genre, so I guess it depends on whether the person is primarily an editor/reviewer or a fiction author. In this case I'd say that she is primarily a fiction author. Moreover, she's been more active as "Pauline E. Dungate" over the last 20 years, so I would be in favor of changing the canonical name to Dungate. Ahasuerus 11:18, 21 September 2018 (EDT)
I think (not entirely sure) that Morgan is her legal name; under that name she's been pretty active in literary and fannish organizations. However, a Google search shows quite a lot of web presence as Dungate too, including interviews and so forth. I agree with changing the canonical name. --Vasha (cazadora de tildes) 16:22, 21 September 2018 (EDT)

O. M. Grey canonical name

Here's an obvious one: Christine Rose's canonical name should clearly be changed to O. M. Grey. If no one objects, I'll do that tomorrow. --Vasha (cazadora de tildes) 16:25, 21 September 2018 (EDT)

"Diff Publications" renamed

The option previously known as "Diff Publications" is now called "Compare Publications". Ahasuerus 10:06, 22 September 2018 (EDT)

Changes to the way submitted Notes/Synopses are displayed

The way submitted notes and synopses are displayed on post-submission/moderator approval Web pages has been changed. For changed notes/synopses a summary of the change is displayed in the Warnings column. Modified, deleted and added lines are displayed with a leading "-" or "+" sign as appropriate. The changed data is displayed "raw", without HTML formatting, in order to make it easier to spot subtle differences.

The new functionality is rather rudimentary, but hopefully it's better than the old way, which often involved staring at multiple lines of near-identical text and trying to figure out what has been changed. Ahasuerus 20:27, 23 September 2018 (EDT)

Fantastic, many thanks! That's very helpful and will save lots of time. Jens Hitspacebar 13:35, 24 September 2018 (EDT)
I knew I wasn't the only one who couldn't do "diff" as fast as a computer! (Fixer tells me that it's only to be expected from carbon-based lifeforms, but he won't hold it against us.) Ahasuerus 14:21, 24 September 2018 (EDT)

Claire Delacroix vs. Deborah Cooke

Back in 2008 Deborah Cooke had two series launched. The first one, Dragonfire, was published by Signet and used her legal name. The second one, Prometheus Project, was published by Tor and used "Claire Delacroix". At the time we decided to go with "Claire Delacroix" as her canonical name, probably because she had also had a few novellas published under that name.

As of 2018 she has had a lot more books published as "Deborah Cooke" than as "Claire Delacroix". She still occasionally publishes new works as Delacroix (e.g. this 2018 novel), but "Deborah Cooke" is clearly the primary name. Even her Tor books have been reprinted as by Cooke. Calling for volunteers who would be willing to work on reversing the canonical name/pseudonym relationship. Ahasuerus 14:33, 24 September 2018 (EDT)

I will do that just as soon as I finish with Pauline E. Dungate! --Vasha (cazadora de tildes) 17:44, 24 September 2018 (EDT)
Thanks! Ahasuerus 17:49, 24 September 2018 (EDT)
There's three names involved here, when do I get the third part?--Dirk P Broer 19:39, 24 September 2018 (EDT)
Which one is the third one? Claire Cross, the pseudonym which she used in the 1990s? It looks like it has already been re-pointed to Deborah Cooke. Ahasuerus 20:08, 24 September 2018 (EDT)
I think it is all correct now --Vasha (cazadora de tildes) 21:07, 24 September 2018 (EDT)
A couple of dates had to be adjusted -- the canonical title uses the date of the variant title if the VT was published first -- but otherwise everything looks good. Thanks for working on this author! Ahasuerus 21:34, 24 September 2018 (EDT)

Position of editing tools in sidebar

I'd like to put this to a vote: Personally, I would like to see Editing Tools moved above Other Sites in the left sidebar, so as not to have to scroll down every time I make a variant, etc. What do other people think? --Vasha (cazadora de tildes) 17:43, 24 September 2018 (EDT)

Well, the original reasons why "Editing Tools" and "Add New Data" are displayed at the bottom of the navigation bar were:
  • separate editing options from other menu options
  • give a higher profile to menu options which non-editors would be accessing
Moving "Editing Tools" up would split the editing options and make it harder for non-editors to get to the "Other Sites" section.
That said, one way to alleviate the need for scrolling would be to convert the main navigation bar sections (Logged In As, Other Pages, Editing Tools, Add New Data) to on-demand drop-down lists similar to the list currently used by "Other Sites". Unfortunately, last I heard, Other Sites were still not working correctly for mobile devices that use iOS.
In addition, at one point I proposed moving the navigation bar from the left side to the top of the page. It would free up a fair amount of real estate, which some of our tables need badly. It would also eliminate the need for scrolling. However, first we need to resolve the iOS issue.
For now, I think I should be able to move "Policies" and "License" to the bottom bar without causing any issues. Ahasuerus 18:10, 24 September 2018 (EDT)
Just confirming that "Other Sites" indeed does not work on IOS/IPhone's Safari (the native browser). If the rest of the menus are converted, the site will be unusable on these devices. :( Annie 20:13, 1 October 2018 (EDT)
Thanks for the confirmation! Some stackexchange discussions seem to suggest that there are ways to get iOS-based browsers to handle this type of menus properly. Would anyone happen to know iOS developers who may know more about this issue? I could experiment on my end, but I don't have an iOS device. Ahasuerus 20:45, 1 October 2018 (EDT)

Language groups/families

As many of you know, our current language policy is to support ISO 639-2-recognized languages. The ISO 639-2 standard has individual codes for popular languages and for some less popular languages. The majority of less popular languages are grouped under language families/groups like "Algonquian languages", "Karen languages", etc.

Following the ISO 639-2 standard, we added "Mayan languages" a couple of years ago. Based on this recent discussion of (mostly) African languages, I am about to add 20 more language codes. 6 of them are language families/groups:

  • Nilo-Saharan languages
  • Bantu languages
  • Niger-Kordofanian languages
  • Central American Indian languages
  • Creoles and pidgins, French-based
  • Creoles and pidgins, English-based

In an earlier comment Vasha suggested that it may be better to display these language groups using the word "language" instead of "languages": "Nilo-Saharan language", "Bantu language", etc.

After thinking about it, I am inclined to go with the "Mayan languages" precedent and use the word "languages". "Creole and pidgin, French-based" seems less clear than "Creoles and pidgins, French-based". Also, the plural form of "Central American Indian languages" etc emphasizes that it's a member of a language group as opposed to some language called "Central American Indian".

Thoughts? Ahasuerus 13:26, 25 September 2018 (EDT)

This field identifies what language the work is in, that is, it fills in the blank in the sentence "This work is in _____" The equivalent of "in French" is "in [a] Central American Indian language." --Vasha (cazadora de tildes) 13:45, 25 September 2018 (EDT)
I guess the difference between French and Bantu/Central American Indian/etc is that the former refers to "the French language" ("the one and only") while the latter refers to "a Bantu/Central American Indian/etc language" ("one of many".) Unfortunately, I can't think of a way to convey this difference without using an article or the plural form :(
It's even worse when dealing with creoles/pidgins. "A creole and pidgin, French-based" doesn't make sense. Perhaps "a French-based creole/pidgin"? Ahasuerus 14:45, 25 September 2018 (EDT)
Hmm, to me the fact that "language" is in lowercase sufficiently conveys that it is not the name of an actual language. But we need to hear from some people further outside the discussion on that. (as for creoles, it's "Creole OR pidgin, French-based") --Vasha (cazadora de tildes) 14:50, 25 September 2018 (EDT)
Well, that's what the ISO standard calls them: "Creoles and pidgins, French-based", "Creoles and pidgins, English-based", etc. "And" makes sense when describing a group of languages because the same code covers both creoles and pidgins. If we are to use the singular form ("creole", "pidgin"), we need to adjust the name. Ahasuerus 15:05, 25 September 2018 (EDT)

(unindent) After thinking some more about it, I agree that our best bet is to use the lower case form of the word "language" to indicate that it's "one of many". It's not perfect, but I agree that it's better than the plural form.

The first step will be to change "Mayan languages" to "Mayan language" in the software. If it doesn't cause any issues -- which it shouldn't, but you never know -- I will go ahead and add the languages discussed above. Ahasuerus 17:03, 28 September 2018 (EDT)

The change has been made. It's not retroactive due to the way I implemented language support back in 2010-2011 (a bad design choice which would be time-consuming to undo.) For this reason old submissions still show "Mayan languages" instead of "Mayan language" when you pull them up, but there are only 3 of them. Ahasuerus 17:29, 28 September 2018 (EDT)
Those three can be fixed by changing them to some other language and then back to Mayan. --Vasha (cazadora de tildes) 18:07, 28 September 2018 (EDT)
Oh no, the actual author records are OK, but the 3 submissions that set the language (like this one) still say "Mayan languages". It's not likely to be an issue since they were created and approved in 2017. Ahasuerus 18:14, 28 September 2018 (EDT)

Added languages - Part 1

The following languages have been added: 

+----------------------------------+
| Nilo-Saharan language            |
| Bambara                          |
| Bantu language                   |
| Niger-Kordofanian language       |
| Ewe                              |
| Igbo                             |
| Kamba                            |
| Kannada                          |
| Kikuyu/Gikuyu                    |
| Kurdish                          |
| Lingala                          |
| Creole or pidgin, French-based   |
| Central American Indian language |
| Nandi                            |
| Creole or pidgin, English-based  |
| Tigre                            |
| Tigrinya                         |
| Tsonga                           |
| Tswana                           |
| Zulu                             |
+----------------------------------+

Ahasuerus 18:46, 29 September 2018 (ED

Great, thanks. --Vasha (cazadora de tildes) 15:29, 30 September 2018 (EDT)

Added Languages - Part 2

The following languages have been added:

  • Acoli
  • Fulah
  • Ganda
  • Kinyarwanda
  • Luo
  • Mandingo
  • Oriya
  • Pedi/Sepedi/Northern Sotho
  • South Ndebele
  • Southern Sotho
  • Standard Moroccan Tamazight
  • Wolof
  • North Ndebele

As I mentioned earlier, for now we use their ISO 639-2 names. AFAIK, this gives us what we need to enter the anthology which originally prompted this discussion. Ahasuerus 19:38, 1 October 2018 (EDT)

Right, they are all in there now. I just am going to keep arguing with you about the names. :-) --Vasha (cazadora de tildes) 19:42, 1 October 2018 (EDT)
It's a frustratingly complicated area for sure. I talked to a native speaker of Luganda/Ganda earlier today and it left me more confused than ever... Ahasuerus 20:52, 1 October 2018 (EDT)
Funny coincidence ... I just met a new neighbor today, and she's from Uganda. I asked her what her native language was, and she said "Luganda." Said she'd heard the name "Ganda" but it didn't seem right to her. --Vasha (cazadora de tildes) 19:04, 2 October 2018 (EDT)

New cleanup report - Magazine issues without fiction titles

A new cleanup report, "Magazines without Fiction Titles", has been deployed. It's similar to "Anthologies and Collections without Fiction Titles". The data will become available tomorrow morning. Ahasuerus 15:00, 2 October 2018 (EDT)

Will we be able to ignore? Because we have things like The New York Review of Science Fiction and Foundation that will pop up immediately - and these will never get resolved if we cannot ignore. And I would fight anyone that claims that these are out of scope :) Annie 15:12, 2 October 2018 (EDT)
Oh, sure. This report is basically a clone of "Anthologies and Collections without Fiction Titles", which supports the ability to ignore pubs. While I was testing it, I "ignored" a bunch of Locus issues and everything worked as expected. Ahasuerus 15:44, 2 October 2018 (EDT)
Oh yes, Locus as well. There will be a lot of ignores... Thanks for the confirmation! Annie 16:11, 2 October 2018 (EDT)
Any chance to "un-ignore" two records? this one and this one? If not, I will just keep them here as a record that they need content. Sorry - my finger was in the wrong line... Annie 14:56, 4 October 2018 (EDT)
Fixed.--Rkihara 12:15, 15 October 2018 (EDT)
Thanks a lot! Annie 12:38, 15 October 2018 (EDT)
I am afraid the ability to "unignore" records is currently unsupported. Since we have FR 768, "Add the ability to view 'ignored' records found by a cleanup report", I will go ahead and add the requested functionality to the FR. Ahasuerus 15:18, 4 October 2018 (EDT)
Suspected so but had to ask. Thanks! Will see if I can find the content for these two later. Annie 15:19, 4 October 2018 (EDT)

(unindent) Quick question - when something is solved, it looks like you need to wait for the nightly report for it to clear - see this one - Apex Magazine, March 2018 is now fixed but it is still in the list). Intentional? Annie 18:08, 4 October 2018 (EDT)

If I recall correctly, the cleanup report that I used as the template for these 2 reports had been coded that way for performance reasons. However, the new reports are unlikely to run into the same performance issue due to the way they are coded. Let me see what I can do... Ahasuerus 18:24, 4 October 2018 (EDT)
Done! Ahasuerus 19:47, 4 October 2018 (EDT)
Ah, that was quick! Thanks! Annie 11:37, 5 October 2018 (EDT)

NEED - to remove or not, that's the question...

Hello. I came across this title: NEEd. I read all (most) synopses and reviews (Amazon, Goodreads, bol.com,...) but couldn't find the slightest hint that this is spec-fic, except for the fact that Amazon catalogued it as such. Delete from the database? Flag as non-spec-fic with a note explaining? Other? Thanks! MagicUnk 15:51, 3 October 2018 (EDT)

From the descriptions, it sounds like it's somewhere between a thriller and near-future science fiction, the kind of grey-area that technothrillers inhabit, speaking about the impact of technology just one step away from what we know. If it's in a grey area and some people are categorizing it as speculative, I say keep it. --Vasha (cazadora de tildes) 16:17, 3 October 2018 (EDT)
It's grey all right :-) If no-one else chimes in, I'll follow your lead and keep it. Thanks! MagicUnk 18:05, 3 October 2018 (EDT)

Walker Books US (US) / Candlewick Press

Publisher Candlewick Press last year acquired US rights to the name "Walker" and now inaugurates its "Walker Books" US list. Today I updated a few records, mainly for publishers, but also one publication record P679266, which introduces the publisher name "Walker Books (US)".

1. I understand that any information added to the new publisher page will be deleted if its only publication record is revised to change the name. (Is it simply lost? That seems to me poor practice.)

2. Anyway, this is a good time to ask what should be the criteria for choosing one publisher name or another. Are we moving toward use of long spaced-slash(" / ") names whenever a hierarchical relationship is known? If so, which hierarchical relationships (stated "imprint", division, etc)? In this case:

  • Walker Books (US) --temporarily in the database after approval of my submission last hour
  • Walker Books U.S. (over a division of candlewick press) --homepage display; we don't use dots in this context, i understand
  • Walker Books US --Publishers Weekly in each its last two issues covers one publication evidently from the new list, and there designates the publisher "Walker Books Us"; Amazon reports "Walker Books US" for those two books
  • Walker Books / Candlewick Press --technically this one truly represents both imprint and division, i understand

One Amazon "Look inside" a Kindle edition (at Amazon US, the "other book", not in the database) shows 'title page'/screen with footer simply "Walker Books". Its copyright page/screen displays finally:

Walker Books
a division of
Candlewick Press
99 Dover Street
Somerville, Massachusetts 02144

"Look inside" the hardcover edition of "our book", for me now, does not show the title page, but a copyright page with the same display quoted above (at Amazon US, here now as the final screen).

One of those two "Looks inside" will be adequate for you when you read this, I hope, knowing that selection varies. --Pwendt|talk 19:22, 4 October 2018 (EDT)

Canonical name change: Julia K. Patt

Unless anyone objects, I am going to change Julia Patt's canonical name to Julia K. Patt (the way she has it on her website, for one thing). --Vasha (cazadora de tildes) 23:31, 4 October 2018 (EDT)

You may also want to look through some of the later ones that miss the K. - at least one actually has the K. on its site (this one while we do not). It may be a timing thing (archive.org should be able to help) but just heads up. Annie 09:57, 5 October 2018 (EDT)
That one is correct because it is "Julia Patt" in the actual recording. --Vasha (cazadora de tildes) 12:28, 5 October 2018 (EDT)
Then a note is in order for the discrepancy between the web page and the recording - the same way we do that when a table of contents and a story title page differ. Annie 12:33, 5 October 2018 (EDT)

Canonical name changes: L. H. Moore, T. J. Berry, Laura Jamez

Three more changes needed: Lawana Holland-Moore to L. H. Moore; T. Jane Berry to T. J. Berry; L. E. Jamez to Laura Jamez --Vasha (cazadora de tildes) 14:16, 5 October 2018 (EDT)

Omnibuses without Contents Titles

The cleanup report Omnibuses without Contents Titles has been made available to non-moderators. Only moderators are able to "ignore" records. The change is effective immediately. Ahasuerus 15:16, 6 October 2018 (EDT)

"Pseudonym" vs. "alternative name"

The recent discussion of canonical names on the Rules and Standards page pointed out that the way we display what we call "pseudonyms" can be confusing. Here is what I wrote during the discussion:

  • At the moment William Fitzgerald Jenkins says "Pseudonym. See: Murray Leinster (or view all titles by this pseudonym)". Then, when you follow the link to the Murray Leinster page, you are told that "William Fitzgerald Jenkins" was his legal name, which is confusing. Similarly, Владимир Набоков tells you that it's a "pseudonym" even though it's merely the Russian form of Vladimir Nabokov's name.
  • ... the word "Pseudonym", which we use on Summary pages, could be replaced with something more generic -- like "Alternative name" -- which would help minimize confusion when our "pseudonym" is actually the person's legal name (see the Murray Leinster/Simon Hawke examples above.)

It seems like changing "Pseudonym" to "Alternative name" would be the low-hanging fruit in this case. If we decide to do that, we will presumably want to change "Pseudonym" to "Alternative name" in regular search, Advanced Author Search and on the "Make/Remove a Pseudonym" page. A few other places will need to be tweaked, but nothing significant. Of course, Help will need to be adjusted as well.

Does this make sense? Anything that I may be missing? Is there anything better than "Alternative name"? (We already say "Used As Alternate Name By" on Summary pages, so in a way it would be just streamlining the language.) Ahasuerus 17:59, 6 October 2018 (EDT)

Yep, that's good. Also covers the case where the "alternate name" is due to a misprint. --Vasha (cazadora de tildes) 18:13, 6 October 2018 (EDT)
If we used "Also published under:" (or "Also published as:"), it would (at least partially) address the transgender issue being discussed elsewhere. ···日本穣 · 投稿 · Talk to Nihonjoe 18:20, 8 October 2018 (EDT)

(unindent) The software has been changed to display "Alternate Name" instead of "Pseudonym". I believe all occurrences of the word "pseudonym" have been replaced except in mouse-over Help where it is used appropriately. If I missed anything, please let me know. Ahasuerus 15:24, 17 October 2018 (EDT)

Help has been updated. Ahasuerus 17:48, 17 October 2018 (EDT)
Help has been further cleaned up. While I was at it, I also deleted or rewrote many obsolete and/or ambiguous paragraphs which were created in the early days of ISFDB 2.0 when the software was very different. Some "How To" pages will also need to be updated. Ahasuerus 15:34, 19 October 2018 (EDT)

Web API enhancements

The part of the Web API responsible for retrieving publication data in response to third party queries has been enhanced. It now correctly returns all publications whose ISBN matches the queried ISBNs regardless of how many variations of that ISBN (ISBN-10 vs. ISBN-13) we have on file. In addition, non-standard dates (0000-00-00, 8888-00-00 and 9999-00-00) are now returned in the format that we use on bibliographic pages.

This is step one in a series of Web API enhancements requested by Fixer in order to facilitate building submissions for ISBN-less pubs. Due to the recent increase in the number of ISBN-less pubs, the fact that Fixer can only create submissions for ISBN-enabled pubs has become a problem and I am working on addressing it. Ahasuerus 14:13, 8 October 2018 (EDT)

Third parties can now use External IDs (ASINs, LCCNs, OCLC numbers, etc) to query the ISFDB Web API. The documentation page has been updated. Ahasuerus 17:32, 8 October 2018 (EDT)
Thanks for updating the APIs! Annie 17:38, 8 October 2018 (EDT)
Sure thing! Fixer says that he will give me a biscuit and even take me for an extra long walk tonight. Ahasuerus 17:56, 8 October 2018 (EDT)

(unindent) Fixer has been upgraded to leverage the new API and to submit ISBN-less publications. At the moment it's not as robust as the rest of Fixer's logic, e.g. it doesn't support internal prioritization, but it lets us handle ASIN-only ebooks in a semi-automated fashion. I plan to use J-Novel Club, which didn't use ISBNs in 2016 and early 2017, as a guinea pig. Ahasuerus 14:39, 15 October 2018 (EDT)

Development server -- technical difficulties

The development server is experiencing technical difficulties at the moment. If I disappear for a couple of days, I am probably deep inside its guts trying to resurrect the beast. Ahasuerus 13:09, 16 October 2018 (EDT)

Watch for facehuggers. The cthulhu are your friends. --Marc Kupper 18:17, 16 October 2018 (EDT)
Thanks for the tips! The development server is now fully operational. Fixer says "Not that I absolutely need independently-turreted 200cm Hellbores on this backward planet, but it's the thought that counts." Ahasuerus 17:12, 17 October 2018 (EDT)

Montenegrin

Can we add Montenegrin (cnr in iso639-2)? Ognjen Spahić does not write in Serbian and the translation is clearly marked as translation from Montenegrin (for example in the award announcement). Considering that iso639-2 recognizes it as a separate language, I would rather not have it lumped with Serbian here... Annie 20:04, 17 October 2018 (EDT)

Done! ISO 639-2-recognized languages are child's play compared to the rest of them :) Ahasuerus 22:20, 17 October 2018 (EDT)
Thanks. I remembered that you mentioned that so did my homework and pulled the code while I was at it. :) Annie 22:35, 17 October 2018 (EDT)

Dangling Propositions

DANGLING PROPOSITIONS: "The Superstoic" "Instrument" "Not to Behold", by Billy Sledge, is available as both an ebook and a paperback on Amazon Books. —The preceding unsigned comment was added by Bsledge (talk • contribs) .

Added -- thanks! Ahasuerus 14:16, 20 October 2018 (EDT)

"Juvenile" chapbooks—search advice?

I have been marking the CHAPBOOK record juvenile if the contained story is juvenile, but it just occurred to me that that doesn't entirely make sense; a CHAPBOOK has no text and can't really be juvenile or not. --Vasha (cazadora de tildes) 17:04, 20 October 2018 (EDT)

Well, COLLECTIONs can be "juvenile" and you can think of CHAPBOOKs as single-story COLLECTIONs. Ahasuerus 18:04, 20 October 2018 (EDT)

Be that as it may, what I really want is an easy way to find chapbooks with juvenile stories in them, whether they're marked or not. Can anyone think of a way to search for them? --Vasha (cazadora de tildes) 17:04, 20 October 2018 (EDT)

It can be done with a custom database search run against a recent backup, but I can't think of a single Advanced Search query that would do it. Depending on the ultimate goal, it may be doable via a new cleanup report. Ahasuerus 18:04, 20 October 2018 (EDT)
Reasons for doing this ... I have been trying to check newly-entered 2018 short fiction to make sure it has length specified if possible and make sure it is really first published in 2018. To make the task a little more manageable, I decided to ignore juvenile fiction. So, ideally I look at non-juvenile anths, colls, and magazines, see if they need more data or contents added, and then mop up remaining short fiction by looking at non-juvenile chapbooks. It would speed things up if I could eliminate the juvenile ones in one step.
If marking chapbooks juvenile is legit, then they should all be marked. Reason enough for a cleanup report. --Vasha (cazadora de tildes) 18:34, 20 October 2018 (EDT)
Sounds good. FR 1206 has been created. Ahasuerus 12:46, 21 October 2018 (EDT)
There are probably a few juvenile chapbooks with non-juvenile Shortfiction too; I know I found one once. Maybe you could generalize the report to mismatches of either type. --Vasha (cazadora de tildes) 14:24, 21 October 2018 (EDT)
I guess it raises a larger question: do we want all four title flags -- juvenile, non-genre, novelization, and graphic -- to match for CHAPBOOK/SHORTFICTION pairs? Ahasuerus 15:12, 21 October 2018 (EDT)
Good question, I don't know. In the case of "juvenile," the match is not obligatory because there could be good reasons for the chapbook to be juvenile and the story not; this juvenile edition of a Kafka story for example. The others ... I can't think of a reason why they might mismatch. --Vasha (cazadora de tildes) 15:58, 21 October 2018 (EDT)
Hm... It looks like this chapbook reprinted the original (well, translated) text of the Kafka story without making any changes, but the presentation made it look like a juvenile, right?
It raises an interesting question. Many classic works which were originally written with adult audiences in mind have had juvenile-friendly editions: Robinson Crusoe, Gulliver's Travels, etc. Similarly, the Harry Potter books have been published with different covers, some aimed at adults and some at kids. Sometimes Harry Potter publishers even state that it's an "adult edition" vs. a "juvenile edition."
For novels, we can't capture this information except in Notes because the juvenile flag exists at the title level. For chapbooks, we have the ability to capture it, but I am not sure it's ideal. What happens if a publisher prints two versions of a chapbook, one for adults and one for kids? Should we have two separate CHAPBOOK titles for the book? Ahasuerus 10:53, 22 October 2018 (EDT)
It is a bit of a mess. The theory that a chapbook is just a neutral container for for a story breaks down a bit because of all the other things besides the story it can contain: essays, illustrations, etc. Another time when this theory got challenged was when I entered a review of a heavily-illustrated chapbook that talked as much about the illustrations as about the story (the story had been published before but the illustrations were new)—it is standard to link the review to the SHORTFICTION record in reviews of chapbooks, so I did that and made a note that it was a review of the illustrated chapbook edition. That case challenges the logic of linking to the SHORTFICTION rather than the title which contains both the story and the illustrations. So maybe we should be paying more attention to chapbooks as something in their own right, with their own properties: the sum total of all their contents, and the editorial presentation of the chapbook, give it the properties. Come to think of it, I could imagine an illustrated chapbook being a "graphic" work even if it contains the word-for-word text of a story. --Vasha (cazadora de tildes) 23:10, 22 October 2018 (EDT)

(unindent) Backtracking here: we don't need to decide all the theoretical issues right now, if you could just implement the cleanup report in the simple form you first proposed so that I could get on with what I'd be using it for! --Vasha (cazadora de tildes) 23:10, 22 October 2018 (EDT)

Sounds good, I'll see what I can do tomorrow. There are only 272 ISBNs left in Fixer's internal queues for this monthly cycle, so at the moment I am actually ahead of schedule for a change. Ahasuerus 22:32, 24 October 2018 (EDT)
A new cleanup report to find CHAPBBOOK/SHORTFICTION juvenile flag mismatches has been coded and deployed. The data will become available tomorrow morning. Ahasuerus 16:47, 25 October 2018 (EDT)
Thanks a lot! --Vasha (cazadora de tildes) 17:00, 25 October 2018 (EDT)

Multiple series - a stopgap measure?

While allowing a title (or a publication?) to be in multiple series is still on the drawing board, could we consider a stop-gap measure of creating a template (or two) that would at least allow us to a) document how desirable the feature is and b) keep us from losing track of which entries would need to be updated once the feature was allowed and c) possibly allow for more thorough searches? ../Doug H 16:00, 21 October 2018 (EDT)

P.S. Earlier discussions found no reason to have multiple/nested publication series. Jules Verne's Voyages Extraordinaire was essentially a publication series, but the books were also part of either Collection Hetzel, Collection Hachette or Magasin d'Education et de Recreation. ../Doug H 16:00, 21 October 2018 (EDT)

I have seen quite a few cases of books in multiple publication series. All the examples I can think of right now are Spanish-language publications. --Vasha (cazadora de tildes) 17:10, 21 October 2018 (EDT)
I have seen a few English-language pubs that belonged to 2 separate publication series.
Actually, allowing multiple publication series per publication record wouldn't be too hard to do because publication series cannot be nested. Ahasuerus 20:04, 21 October 2018 (EDT)
Example of nested publication series, from LTF: Criptonomicón I. El código Enigma as "Byblos 1362" and "Byblos Neal Stephenson 1." --Vasha (cazadora de tildes) 21:12, 21 October 2018 (EDT)
I suppose various "Masterworks" pub series could also be usefully organized hierarchically. Ahasuerus 09:50, 22 October 2018 (EDT)
Title series present a more difficult challenge. If a title belongs to two separate sub-series within the same parent series, as was the case with R. A. Salvatore's Servant of the Shard, the display logic can get hairy. Probably still doable, though. Ahasuerus 20:04, 21 October 2018 (EDT)
See also the UniCorp series and its sub-series Trilogía de Benigno Manso. The authors assign those three novels as both 1, 2 and 3 of the Trilogía, and numbers 18, 21, and 26 of the UniCorp series.
The title series issue could be handled by displaying the title twice, if this isn't completely undesirable—probably that's the crux of the matter. The UniCorp example could look like this:
UniCorp
3 Sombras de honor (2008)
....
18 (Also Trilogía de Benigno Manso 1) La embajada (2000)
....
39 La cosecha del centauro (2009)
Trilogía de Benigno Manso
1 (Also UniCorp 18) La embajada (2000)
What do you think? --Vasha (cazadora de tildes) 21:12, 21 October 2018 (EDT)
Do not add more stuff between the title and the number - it is already hard to read with some long titles and adding more stuff won't make it easier to read or to copy off the page when you want to. I am all for having it at the end of the line - just after the year and the "only by" when these a presented but not that early on the line. Annie 23:21, 21 October 2018 (EDT)
Keep in mind that a true "multi-field" can have any number of values. For example, What Lay Beyond, book 7 in our "Star Trek: Gateways" crossover series, is also a part of the following timelines/series:
  • Star Trek TOS
  • Star Trek Challenger
  • Star Trek TNG
  • Star Trek DS9
  • Star Trek Voyager
  • Star Trek New Frontier
That's what makes the issue so thorny. Ahasuerus 09:58, 22 October 2018 (EDT)
Yeah, there is that one. There are a few like that in the Trek cannon, not just the Gateways. And then there are a few fantasy series that have subseries inside of the series and all kind of other... fun. Annie 17:33, 22 October 2018 (EDT)
Another display idea (just a thought--I think this looks OK, even for the really long one) I put the "also part of" in bold-itals to distinguish it from the Translations and Variants that are also in the same place under the title. I think if there were both translations and multiple series then the series notation would go under the translation notation. --Vasha (cazadora de tildes) 19:39, 27 October 2018 (EDT)
UniCorp
12 La voz del héroe (1997) [SF] by Eduardo Gallego and Guillem Sánchez
13 Nàufrags en la nit (1998) [SF] by Eduardo Gallego and Guillem Sánchez also appeared as:
◾ Translation: Un cruce en la noche [Spanish] (2004)
14 Dime con quién andas ... (1996) [SF] by Guillem Sánchez and Eduardo Gallego
17 Después del Desastre (2002) [SF] by Eduardo Gallego and Guillem Sánchez
18 La embajada (2000) by Eduardo Gallego and Guillem Sánchez
Also part of: Trilogía de Benigno Manso (1)
19 La llanura (1998) [SF] by Eduardo Gallego and Guillem Sánchez
20 Fortaleza de invicta castidad (2001) [SF] by Eduardo Gallego and Guillem Sánchez
21 Asedro (2001) by Eduardo Gallego and Guillem Sánchez
Also part of: Trilogía de Benigno Manso (2)
22 Inmigrantes (1996) [SF] by Eduardo Gallego and Guillem Sánchez

Star Trek Gateways
7 What Lay Beyond (2001) [A] by Keith R. A. DeCandido and Susan Wright and Diane Carey and Robert Greenberger and Peter David and Christie Golden
Also part of: Star Trek TOS, Star Trek Challenger, Star Trek TNG, Star Trek DS9, Star Trek Voyager, Star Trek New Frontier

(unindent) I didn't really want to re-hash the reasons for and against implementing multiple series or the possible implementations. I was hoping a Template (or one each for title and publisher series) would be simple to implement, provide consistency of entry and display, track prospective entries and identify possible issues for such a discussion. ../Doug H 09:02, 22 October 2018 (EDT)

A template or two would be easy to add. Would something like "MultipleSeries" and "MutliplePubSeries" be sufficient? Ahasuerus 09:47, 22 October 2018 (EDT)
Would "AdditionalTitleSeries" and "AdditionalPubSeries" be clearer? ../Doug H 09:57, 22 October 2018 (EDT)
Sure, we can do that. Ahasuerus 11:11, 22 October 2018 (EDT)
Do templates support abbreviations? ../Doug H 09:57, 22 October 2018 (EDT)
Template names can't be abbreviated at this time. We could create two differently named templates with the same functionality, but I am concerned that it may confuse less experienced editors. Ahasuerus 11:11, 22 October 2018 (EDT)
I'd go for clarity over brevity. One long name each, with Additional making it clearer it is to support series other than the one already specified by the Series attribute.
I've gotten used to Tr for translate, any chance of ATS/APS? ../Doug H 09:57, 22 October 2018 (EDT)
We have full control over template names, so we can do whatever we want. A lot of our template names are abbreviations, although most of them are names of established third party sites like OCLC and BnF. Ahasuerus 11:11, 22 October 2018 (EDT)
Presumably parameters would be series name and optional sequence. ../Doug H 09:57, 22 October 2018 (EDT)
I am afraid that, unlike the Wiki software, the ISFDB software supports only one parameter per template at this time. Given this limitation, it would have to be the "other" series name; series numbers would be unsupported. Unfortunately, series names are less stable than record numbers. Also, it would only work for titles which belong to 2 series. Ahasuerus 11:11, 22 October 2018 (EDT)
This is just documentation, names are good enough. As long as the text wrapper for the templates allow one to include the sequence if needed it will work. Based on the ISBN template for additional ISBNs (no longer necessary I presume), my suggestion is to display the words "Additional title|publication series" followed by a space and the specified parameter. Although to follow through on the idea, the names should be shortened to TitleSeries and PubSeries. ../Doug H 11:40, 22 October 2018 (EDT)
So the end result for R. A. Salvatore's Servant of the Shard would be "Additional title series Forgotten Realms: The Sellswords, volume 1", right? Would "Also in title series Forgotten Realms: The Sellswords, volume 1" be clearer? Ahasuerus 12:50, 22 October 2018 (EDT)
"{{TitleSeries | Forgotten Realms: The Sellswords}}, volume 1" would be my preference to generate your text. ../Doug H 14:41, 22 October 2018 (EDT)
If I understand everything correctly, then the current version of the proposal is to create two linking templates, {{TitleSeries}} and {{PubSeries}}. Each one would take one parameter. When displayed, the proposed templates would expand to "Also in title series NNN" and "Also in publication series NNN". NNN would be replaced with a regular Search link to the title/publication series with the parameter value used as the search value. It would be similar to the way "Husband of {{A|Tabitha King}}." is replaced with
Husband of <a href="http://www.isfdb.org/cgi-bin/se.cgi?arg=Tabitha%20King&type=Name&mode=exact">Tabitha King</a>
on Stephen King's Summary page. Is that about right? Ahasuerus 16:13, 22 October 2018 (EDT)
I hadn't been thinking it was a linking template. If you do that, then I'd drop the extra text of "Also in" and consider dropping the "title series" and "publication series" to make it behave exactly the same way as the {{A|}} and let people string together sentences the way they want. ../Doug H 17:28, 22 October 2018 (EDT)
Sure, we can do that. Ahasuerus 11:36, 23 October 2018 (EDT)
P.S. If we do, perhaps we should call the new templates something like {{S}} and {{PubS}} to be consistent. Ahasuerus 11:55, 23 October 2018 (EDT)
While I am all for uniformity, I would make the case that we should have separate templates than standard S and PubS ones if we plan to change the UI at some point to get them shown differently. I can see myself using S or PubS in all kinds of notes to reference a series/pub series and not just for indicating inclusion. We can just do that of course but then we are facing yet another long cleanup in splitting the "this is also part of a series" from "and we just references a series"... On a very separate note, if we add them, they also need to be added to the report that checks for invalid ISFDB references :) Annie 12:55, 23 October 2018 (EDT)
Fair enough. In that case, perhaps we should create two sets of templates:
  • "S" and "PubS" for arbitrary references to series/pub series
  • "MultiS" and "MultiPubS" for multi-series titles and pubs
Ahasuerus 15:33, 23 October 2018 (EDT)
Yep - sounds good to me. Annie 15:58, 23 October 2018 (EDT)
If the series doesn't exist, what happens? ../Doug H 17:28, 22 October 2018 (EDT)
You'll get a blank page which will say A search for 'test series' found 0 matches. Ahasuerus 11:36, 23 October 2018 (EDT)
I like the look of using a bullet to denote the sequence (i.e. • 1) the way it shows up on the title reference on the publication. Is there a template for bullet? ../Doug H 14:41, 22 October 2018 (EDT)
Not at this time, but we could easily create one if desired. Ahasuerus 16:13, 22 October 2018 (EDT)
Anyone who can learn the name of the bullet template can learn to type "&bull;".--Vasha (cazadora de tildes) 13:11, 23 October 2018 (EDT)
I guess you could cut/paste the character. Anyway keeping just the series name in the template should simplify organizing a conversion if we ever get around to it. I figured the "Also in" text didn't help with readability. ../Doug H 14:41, 22 October 2018 (EDT)
My concern with "Additional title|publication series" was that if a "naive" user were to come across that wording in a Note field, it might not be immediately clear what it was in reference to. Hopefully other editors will chime in re: readability. Ahasuerus 16:13, 22 October 2018 (EDT)
How about "Title also belongs to "name" series" or "This title is also "Test #1"" where the template parameter will need to be the complete string we want to show. Or maybe string 2 templates next to each other ({{AddSeries|Test}}{{number|1}} will become "This title is also in Series Test (as number 1)". If you miss the second template, it does not have the element in the brackets)? Same for pub series. Annie 17:33, 22 October 2018 (EDT)
Also, how would you leverage these templates to handle What Lay Beyond which I mentioned earlier? Use the "Additional title series" template 6 times, once per additional series? Ahasuerus 12:50, 22 October 2018 (EDT)
Most cases have only one additional. For such rare occurrences, repeating the template seems reasonable, especially since it would help with searches. ../Doug H 14:41, 22 October 2018 (EDT)
Not different from multiple templated OCLCs for example - repeat the template as many times as you need to. Annie 17:33, 22 October 2018 (EDT)
Makes sense. Ahasuerus 15:33, 23 October 2018 (EDT)

Finalizing the wording of MultiS and MultiPubS

Now that "S" and"PubS" have been added, we need to finalize the wording of "MultiS" and "MultiPubS". Based on the discussion above, we have the following scenarios:

Publication series:

  • Also part of Ace Double
  • Also volume D-343 in Ace Double

Regular/title series:

  • Also part of Trilogía de Benigno Manso
  • Also volume 1 in Trilogía de Benigno Manso

What should "MultiS" and "MultiPubS" expand to in order to accommodate these scenarios? Ahasuerus 18:29, 26 October 2018 (EDT)

With a bit of rewriting (and a third template ("Vol" for example) - because we cannot pass 2 parameters, right?):
  • {{MultiPubS|Ace Double}}: Also part of Ace Double
  • {{MultiPubS|Ace Double}} {{Vol|1}}: Also part of Ace Double(as volume 1)
Any chance we can make them work both with names and with IDs? I doubt it but have to askAnnie 21:59, 26 October 2018 (EDT)
Not at this time, I am afraid. Ahasuerus 22:07, 26 October 2018 (EDT)

Links from Facebook

If someone posts a link to one of our listings on ISFDB, Facebook now appends a really long Facebook Click ID to the URL (example). Can we update the database to strip the "&fbclid=" and the ID from the URL when it comes here so the links will work? ···日本穣 · 投稿 · Talk to Nihonjoe 16:24, 24 October 2018 (EDT)

It looks like they started doing it earlier this month. I've created FR 1207 to ignore the Facebook parameter - thanks! Ahasuerus 16:58, 24 October 2018 (EDT)
Awesome, thanks! ···日本穣 · 投稿 · Talk to Nihonjoe 17:19, 24 October 2018 (EDT)
After experimenting with this issue, I realized that this is a fairly big can of worms. As Wikipedia explains, most URL queries look like http://example.com/path/to/page?name=ferret&color=purple . Facebook assumes that all Web sites use this format and appends another parameter, "fbclid", to each external URL. They figure that another parameter shouldn't prevent third party Web sites from parsing the rest of them correctly.
However, that's not how most of our Web pages (searches are an exception) work. Our URLs look like http://www.isfdb.org/cgi-bin/title.cgi?2456027 , http://www.isfdb.org/cgi-bin/pl.cgi?689416 and so on. Note that there is no equal sign in these URLs. If we need to pass an additional parameter, we use the "+" sign, e.g. http://www.isfdb.org/cgi-bin/pl.cgi?689416+c .
What this means is that our URLs are incompatible with what the Facebook software expects. It may be possible to beef up our parsing algorithms to extract IDs from the hybrid URLs that Facebook uses, but it's a pretty big deal. For starters, every ISFDB page does its own parameter parsing, so we would first need to centralize the parameter parsing process, which would literally affect every Web page that we have.
Hopefully Facebook will realize that not every Web site uses the URL format that they expect and stop appending "fbclid" to incompatible URLs. Ahasuerus 21:33, 26 October 2018 (EDT)
I doubt that will happen. Facebook doesn't care what a "little" site like ISFDB wants. I see two options: add something to the software that either tracks the link as a referrer link (if that's something useful to do here), or just have it ignore it altogether. I lean toward the latter. Right now, it simply states "Bad Argument", which isn't helpful to anyone trying to link to anything here. ···日本穣 · 投稿 · Talk to Nihonjoe 17:36, 22 January 2019 (EST)
It's a lot of work. Every ISFDB Web page processes its parameters differently. Some expect 1 parameter, some expect 2 or more, some can accept a variable number. Some parameters are numeric and have special processing logic associated with them. Each parameter has to be handled just right in order to avoid security problems.
Rewriting all of that code in order to accommodate Facebook's current practices -- which may change at any time -- wouldn't be a good way to spend resources. At some point we'll need to consolidate the software that handles parameters, at which point it will become doable. Ahasuerus 18:37, 22 January 2019 (EST)
Makes sense. It looks like there are a few browser extensions (at least for Firefox) that remove it from the URL. ···日本穣 · 投稿 · Talk to Nihonjoe 19:13, 22 January 2019 (EST)

Note Search

A new section, "Note Search", has been added to the Advanced Search page. The functionality is relatively basic compared to the main Advanced Search sections and should be self-explanatory. All record types -- authors, awards, publishers, series, etc -- are searched, so it usually takes a few seconds to compile the results. Please note that the search logic also scans the Synopsis data. Ahasuerus 19:52, 24 October 2018 (EDT)

Yey! Thanks for building this! Annie 19:57, 24 October 2018 (EDT)
Awesome! Will it be added to the main search box? ···日本穣 · 投稿 · Talk to Nihonjoe 20:44, 24 October 2018 (EDT)
I don't think it's something that we have discussed before. If there is demand, I can certainly add "Notes" to the regular search box. Like other regular search options, it would assume the "contains" (as opposed to "starts with" etc) parameter. Ahasuerus 21:11, 24 October 2018 (EDT)
How hard is that query on the DB? Everything else looks at a single short-ish field; that one can get a bit gnarly (if you look for "a" for example). Annie 21:13, 24 October 2018 (EDT)
It's rather intensive since each search has to parse up to 90 MB of data. The "regular" search logic doesn't support single character searches for most search types, so at least "a" shoudn't be an issue if we were to add "Note" to the drop-down list. Still, it can take over 5 seconds to complete a Note search, so it's pretty impactful. Ahasuerus 22:29, 24 October 2018 (EDT)
I know that I keep hitting "search" with a wrong category often - while you need to go into the Advanced Search as it is now. And "an" is bad enough anyway. Or "th" :) If everyone wants it, please, do not mind me but I would rather not see it on the outside list... Annie 22:33, 24 October 2018 (EDT)

While we're on the subject of searching—why is it not possible to use the OR operator when searching tags? (I may not understand the answer, but ...) It would be handy to be able to search for "science fiction OR sf," for example. --Vasha (cazadora de tildes) 22:09, 24 October 2018 (EDT)

Actually, it's the other way around: OR is supported but AND is not. A search on vampire OR vampires succeeds while a search on vampires or werewolf fails.
The reasons are highly technical in nature. There are other Advanced Search quirks which I'd like to address, e.g. Bug 690 ("Advanced Searches on 'not exactly' and 'does not contain' can fail") and Bug 571 ("Advanced Search on Web Pages fails for OR searches"), but it would require a fair amount of tinkering. Ahasuerus 22:21, 24 October 2018 (EDT)
Hi Ahasuerus. I was checking both bugs you mention above. What I was wondering, aren't these easily solved by using (left or right) outer join on the involved table fields in your query? And if there're limitations in the querying language you use, the same effect can be achieved with a union. Or am I missing something here? MagicUnk 02:37, 26 October 2018 (EDT)
Yes, outer joins are the way to go and yes, they are supported by the version of MySQL that we are currently using. However -- there is always "however", isn't there? -- our Advanced Search logic is a fairly big can of worms which has evolved over the years. It's vastly better than it was 5-10 years ago, but it's still suboptimal. For starters, it tries to accommodate arbitrary combinations of ANDs/ORs, but doesn't do a good job of it.
The first step will be to eliminate the AND/OR mess. The second step will be to rewrite Advanced Search to address FR 1142 and FR 1143. Once that is done, we will be able to go back and address the outer join issues. No rest for the wicked! :-) Ahasuerus 13:14, 26 October 2018 (EDT)

(unindent) The Note Search has been further enhanced. Authors are now displayed alphabetically based on the directory entry/family name. Notes which leverage the "BREAK" template are now fully displayed. Ahasuerus 13:56, 26 October 2018 (EDT)

A quick question: " Note Search is currently limited to the first 1000 author matches plus up to 1000 other matches. ". Why the authors are singled out here? It may be just my usage pattern but I rarely look for author notes (as opposed to links - there I am more likely to look for authors indeed) so it would be more logical to have either publications or titles being singled out on their own outside of the 1000. Are the notes for authors handled differently in the DB? Annie 14:23, 26 October 2018 (EDT)
That's right, Author Notes, which were added in 2017, are handled differently by the database/software. All other types of notes are stored in one big table, which is ... suboptimally organized. It's one of the few remaining legacies of the "ISFDB 1.0" software which we used in 1995-2005. I plan to rewrite it one of these days. Hopefully sooner rather than later. Ahasuerus 15:38, 26 October 2018 (EDT)
That explains it. Well, I guess I will need to get the numbers under 1000 to see all of the non-publication references :) Thanks! Annie 15:57, 26 October 2018 (EDT)

Reorganizing data-entry fields: how difficult?

While entering new pubs I notice I need to scroll up and down a lot, and do not really have a good overview of what data I've already entered. Looking at the fields and the average length of the data it holds, I was wondering if it's possible/easy to do to rearrange some of the now vertically-arranged fields to horizontal. I don't know if this has been discussed before but it would save space to have, for example, the Juvenile, Novelization, Non-Genre, Graphic Format checkboxes on one line. Likewise, it could save space to have ISBN & Catalog ID fields, and Pub Series & Pub # similarly arranged horizontally. Thoughts? MagicUnk 13:02, 25 October 2018 (EDT)

Just a comment: some people work on small screens often... I often do quick edits from my phone for example and the screen on my home chromebook may not be as small but it still is much smaller that you would think (and fitting all 4 field names and checkbox for example won't work there). And Publication Series can be a long string - making it shorter so we can fit a number next to it does not make sense. If we go for a reordering, can we please make it optional? :) Annie 13:15, 25 October 2018 (EDT)
Moving fields around is easy, we'll just need to make sure that we do it consistently across all data entry forms. I was thinking about putting the four title check-boxes on the same line myself the other day.
Re: Annie's point about small screens, I can see how it would make putting the Series and Pub. Series fields on the same line problematic. Ahasuerus 13:18, 25 October 2018 (EDT)
It is not just small screens I think. I know that we had at least a few editors working under magnification - which will also make the screen unwieldy when it gets too wide. Although the more I think about the 4 checkbox, the more I start agreeing that they take too much space now :) Annie 13:31, 25 October 2018 (EDT)
Just for clarity's sake, the examples I gave above are just that, examples. I did not mean to rearrange in such a way that they would extend beyond the length of the already existing input fields (which are at least 80 chars wide if I counted correctly). Rearranging can be done in such a way that small screens do not suffer. As an example, if you count the characters of the longest label+checkbox, the length is only 19 chars [Graphic˽Format:˽?˽□ (where ˽ denotes space)]. 4 fields x 19 chars = 76 chars max - would fit nicely below the 'Content' bar with space to spare if you consider the 28 positions for the label (which I didn't count).
As for the pub series name & number example: Ahasuerus, can you to a group by max(lenght(string)), count query so we have an idea about the max length of a pub series name? Can't imagine it extend (much) beyond 40 or so chars... Cheers! MagicUnk 18:36, 25 October 2018 (EDT)
Behold -- our longest publication series name, Illustrierte Weltall-Bibliothek - Fesselnde Erzählungen, Abenteuer u. Forschungsreisen aus allen Gebieten des Weltalls! :-) Ahasuerus 20:38, 25 October 2018 (EDT)
Arghlp! So, I guess best not to touch the series fields then. But what about other real-estate-saving shuffling around of fields (like the checkboxes)? Still a good idea? MagicUnk 02:01, 26 October 2018 (EDT)
The three editors who have commented so far all seem to agree that putting the title flags/checkboxes on the same line is a good ideas, so I have created FR 1208 for this enhancement.
Come to think of it, it may also help in other ways. There have been times when I accidentally checked the wrong box. Hopefully displaying them horizontally will make misclicks less likely. Ahasuerus 12:54, 26 October 2018 (EDT)
Another thing that might reduce errors is to make sure the boxes are in the same order everywhere they appear (they currently are not). --Vasha (cazadora de tildes) 14:40, 26 October 2018 (EDT)
Oops, I had no idea! Thanks for pointing it out. Bug 712 has been created. Ahasuerus 15:17, 26 October 2018 (EDT)
Fixed. Ahasuerus 22:18, 26 October 2018 (EDT)
ISBN and Catalog ID on one line is not a bad idea either. --Vasha (cazadora de tildes) 14:31, 26 October 2018 (EDT)
True, but we plan to allow multiple ISBNs per publication -- Real Soon Now (tm) -- at which point things will change. Ahasuerus 15:17, 26 October 2018 (EDT)

Web Page Search

As per FR 1141, "Web Page Search" has been added to the Advanced Search page. The functionality is similar to the previously added Note Search functionality except the search logic checks third party Web site URLs across all record types. For example, here is what you will get if you search for "user". Ahasuerus 23:09, 25 October 2018 (EDT)

Now that's scary - you managed to get it done while I was planning to ask you to do a search at all web pages fields pointing to chpr.at (we had some of .the txt links in the notes (which had been dead for awhile) - I moved those to the new .htm format last night but was not sure what we have in weblinks...). Thanks! Annie 23:31, 25 October 2018 (EDT)
You are welcome! This functionality was originally requested at the same time that the Note search functionality was requested. In addition, the search logic is similar, so once the Note Search module was completed, it was relatively easy to create the Web Page Search module.
In the meantime I have deployed another patch to clean up the way the data is displayed. The most obvious changes are:
  • Third party URLs are now hyperlinked
  • Author names are now alphabetized based on each author's directory entry/family name
Ahasuerus 12:43, 26 October 2018 (EDT)

2 new linking templates: PubS and S

Two new linking templates have been created for publication series and regular series: {{PubS|[pub. series name]}} and {{S|[series name]}}. Help:Using_Templates_and_HTML_in_Note_Fields#Linking_Templates has been updated. Ahasuerus 18:17, 26 October 2018 (EDT)

Very Far Away from Anywhere Else

Usula K. Le Guin's Very Far Away from Anywhere Else is marked "juvenile" and I think it doesn't fit that—the main characters are 17 years old, audience not much younger. The standard codes we follow as a guideline for age ranges (I'm blanking on the name of it) has "juvenile" being up to age 15 or so. Any objection to my removing the juvenile flag? --Vasha (cazadora de tildes) 03:07, 27 October 2018 (EDT)

Sounds like a good plan. Ahasuerus 10:08, 27 October 2018 (EDT)
Not sure if that's rhe right thing to do. Our juvenile flag covers both juvenile and young adult. It is impossible to clearly define, but young adult is targeted to ages 16 to 21 (roughly). So, if that's the target audience, it should remain tagged as juvenile. MagicUnk 03:50, 28 October 2018 (EDT)
Agreed. Template:TitleFields:Juvenile specifically says "targeted at the juvenile or Young Adult market". Maybe we should rename the field (though there is not an easy name that encompasses all that I can think of) or just delete it... -- JLaTondre (talk) 09:27, 28 October 2018 (EDT)
For some reason I thought that the last round of the relevant Rules and Standards discussion didn't explicitly include YA fiction, but I see that I was misremembering. Sorry about that!
That said, I think our current usage may be different. Let me run a few queries to see how many titles with YA/teen tags also have the "juvenile" flag set. If the percentage is as low as I suspect it is, I will post on the R&S page. Ahasuerus 11:16, 28 October 2018 (EDT)
Here are the results. Definitions:
  • A "YA tag" is a tag that starts with "teen " or contains "young adult"/"young-adult"
  • A "juvenile tag" is a tag that starts with "child "/"children" or contains "juvenile"
Note that some titles are on the border between "juvenile" and "YA", so they have both "juvenile" and "YA" tags. With that in mind:
  • Total titles with "YA" tags: 12,047
  • Total titles with "YA" tags and no "juvenile tags": 11,030
  • Titles with YA tags which also have the "Juvenile" flag set: 3,731
  • Titles with YA tags and no juvenile tags which also have the "Juvenile" flag set: 2,732
This means that of the 11,030 "pure" YA titles only 2,732 -- or 24.77% -- have the "Juvenile" flag set. I think this is enough to start a Rules and Standards discussion, so I will re-post the investigation results there. Ahasuerus 12:12, 28 October 2018 (EDT)

Wool-gathering (transferred)

I am transferring here the exchange I've just had with Ahasuerus. Any other commentaries / suggestions / horror screams from the community ?

As I am ploughing (U.S. : plowing) through all sorts of pub series at the moment, a few ideas crossed my mind, which, no doubt, other editors have had before. There is nothing urgent about all this — more wool-gathering than anything else — but if anything can come out of it, all the better.

Crossover series

Would there be a way to make a title (typically, e.g. Frankenstein Meets Dracula) belong to distinct series ? There are more and more stories of this type, mixing up characters from different horizons. Linguist 12:30, 26 October 2018 (EDT).

There is a Feature Request (FR 406) to "Allow multi-series titles" and a related ongoing discussion of overlapping and hierarchical publication series here. Since crossover series are becoming more common, we may want to make this FR a higher priority. It's not that hard to do from a purely technical perspective, but first we need to decide how the software should behave in unusual cases, e.g. what we should do with a title that belongs to 7 series -- see the discussion linked above. Ahasuerus 18:52, 26 October 2018 (EDT)
As Ahasuerus points out, there is already a discussion on this further up the page. It would be better to keep the discussion consolidated there. -- JLaTondre (talk) 09:28, 27 October 2018 (EDT)

Art title series

Could the series concept be applied to art titles ? I tried it once, and the result was that the concerned titles appeared grouped together, but without a common title name. This would mainly concern covers with an identical art element, as part of a book series (as in this one for instance). Linguist 12:30, 26 October 2018 (EDT).

Checking the software, I see that the following title types let you enter series information, but are not organized as series on Summary pages: COVERART, INTERIORART, REVIEW, INTERVIEW. I can't think of a good reason to prevent editors from organizing these types of titles as proper series, so I would support changing the software behavior. Would you like to post a proposal on the Community Portal? Ahasuerus 19:02, 26 October 2018 (EDT)
FR 1213 has been created. Ahasuerus 12:48, 3 November 2018 (EDT)

Viewing title series covers

Would there be a way to view all the cover illustrations of an existing series ? Linguist 12:30, 26 October 2018 (EDT).

At this time you can view all cover images for a publication series -- e.g. Nouveaux Millénaires -- but not for a regular/title series. Since cover images are associated with publication (as opposed to title) records, it didn't seem desirable. However, it wouldn't be that hard to do from the technical perspective and I can certainly implement the functionality if there is support on the Community Portal. Ahasuerus 19:07, 26 October 2018 (EDT)
FR 1214 has been created. Ahasuerus 12:52, 3 November 2018 (EDT)

Viewing an artist's illustrations

Would there be a way to view all the cover illustrations by the same artist ? That would be a great help in finding variants. TIA, Linguist 12:30, 26 October 2018 (EDT).

It's certainly doable. The only concern that I have is that some artists are prolific; loading all of their images may take a long time. If we implement this functionality, we may want to display a warning.
Other than that, it seems like it would be a useful feature. We'll need to think of ways of organizing images by COVERART title, its variants, publication year, etc. Ahasuerus 19:14, 26 October 2018 (EDT)
This was proposed before with a working prototype. See Better way to find varianted or similar cover art and Followup to Better way to find varianted or similar cover art. Stoecker's site is still up and working. The "Dual" mode provides an excellent way to find duplicated / variant covers. -- JLaTondre (talk) 09:28, 27 October 2018 (EDT)
For prolific artists, it may be a possible solution to limit the number of images shown (so you have to fine-tune via advanced search for them). Stonecreek 10:04, 27 October 2018 (EDT)
Pagination would work. Show user configurable number (with some maximum based on performance) of titles in each pane. Allow each pane to be paged through separately. Clicking through vs. scrolling down a continuous page seems a reasonable trade between user ease and performance. -- JLaTondre (talk) 11:12, 27 October 2018 (EDT)
I for one, have also been 'frustrated' with not being able to view all covers of a certain artist, so +1 from me for the show artist cover images FR :) Thanks! MagicUnk 18:15, 27 October 2018 (EDT)
I would love this feature. ···日本穣 · 投稿 · Talk to Nihonjoe 16:11, 30 October 2018 (EDT)
OK, FR 1212 has been created. Ahasuerus 12:45, 3 November 2018 (EDT)

[unindent] If it’s just impossible or too time-consuming, or been tried before and dropped, please don’t bother going into the fine details to explain why. But if one of these vagaries seems technically possible and easy to do, well, why not ? TIA, Linguist 12:30, 26 October 2018 (EDT).

Excellent questions! Ahasuerus 19:14, 26 October 2018 (EDT)

Canonical name change: LeVar Burton

Hi, I want to suggest to suggest to change the name of Levar Burton to LeVar Burton (capital V). That is his proper working name, as seen on all external linked sites. The lower case possibly comes from the cover images of his novel, but those have the name in all caps. The one image that isn't in all caps correctly has the V capitalized. TerokNor 12:41, 30 October 2018 (EDT)

I agree with this. ···日本穣 · 投稿 · Talk to Nihonjoe 15:59, 30 October 2018 (EDT)
Change made. -- JLaTondre (talk) 13:45, 3 November 2018 (EDT)

Merging illustrations

What's the proper procedure for merging this and this without having title variants? user:Rtrace has confirmed they are the same W&B illustration, and the "Tiffany on the Chalk" title is taken from Kidby's website. Circeus 10:37, 1 November 2018 (EDT)

Two options:
* Rename them to have the same title - then merge them. However, if the title of the picture is not in the book, it should not be named that way - we follow the naming inside of the book.
* If the names remain different, they need to be varianted. For art, varianting means: "it is the same picture (more or less - it can have changes in coloring and what's not) but it has a different title in different publications".
Names from the artist's site go into the notes; if the illustration is not named this way IN the book, the title is not used as a title here usually. Being interior art leaves some leeway but... I would still not name it based on a site.
Let me know if any more clarifications are needed or if you need assistance. :) Annie 11:49, 1 November 2018 (EDT)
Please don’t merge or variant those titles. One is an overall interiorart title for an entire book. It contains the other, but also contains the other artwork in the book. --Ron ~ RtraceTalk 13:36, 1 November 2018 (EDT)
They are both identical full-page illustrations. Why shouldn't they be merged? Circeus 13:40, 1 November 2018 (EDT)
Because (looking at Ron's page)the record in Ron's book is NOT JUST for that illustration but for all the internal artwork in the book. Annie 14:44, 1 November 2018 (EDT)
Precisely right. Sorry for the terseness of the previous comment, I was on my cell phone. We have three different ways by which we enter INTERIORART. Unfortunately, we don't have a good way of linking titles for individual artwork to a title that contains multiple artworks. You could certainly add a note on either or both of the title records explaining the relationship. I will note that the individual artwork can be linked with this title. It's a little complicated since one of the pieces is technically a translation. I do question whether the illustration French book really has an English caption. If so, would we still consider the language of that title to be French? Also, does the French book contain only that illustration and omit the headpieces and other decorations? If they are present, there should probably be an overall artwork title for the French translation instead of cataloging only the one illustration. Circeus, do you own or have access to the translation? If so, please verify what artwork exists there and we can figure out how to proceed. Thanks. --Ron ~ RtraceTalk 19:48, 1 November 2018 (EDT)

Three months later.
For what it's worth: In the Contents list for a publication that reprints multiple single illustrations from an earlier INTERIORART work --that is, selections from a previously published set of illustrations-- I would like to see us use titles such as

Alice in Slumberland [1]
Alice in Slumberland [2]

rather than omit disambiguation for the title of the first one. As an alternative, we might disambiguate that first single-illustration excerpt from the original work thus:

Alice in Slumberland (excerpt)
Alice in Slumberland [2]

As a less radical suggestion, we might add such a title disambiguator only if the entire original INTERIORART work is in the database. (Commonly that will be when the first publication of the latter is added to the database. Commonly too, however, we have many-a-record of a publication in which one set of illustrations is published for the first time, but our publication record does not report the illustrations. So the less radical change of title --for the TITLE that represents one illustration later reprinted from a set-- from "Alice in Slumberland" to "Alice in Slumberland [1]" would happen when we add the set of illustrations to our record of its first publication.)

Also less radical, we might assign to a single-illustration excerpt the date of its earliest known publication. "Alice in Slumberland (excerpt)" isn't first published when "Alice in Slumberland" (entire) is first published. --Pwendt|talk 16:56, 25 January 2019 (EST) --Pwendt|talk 16:56, 25 January 2019 (EST)

(re-word and mark-up, above, for clarity)
Either of the less radical suggestions will be adequate to ensure that Alice in Slumberland (1898) does not appear in the database as the title of both the 1898 set of illustrations and any later publication of one illustration from the set.
By the way, can anyone judge how commonly we do have one single-illustration title such as "Alice in Slumberland [2]" now in use for reprints of different illustrations from the original set? --Pwendt|talk 13:05, 26 January 2019 (EST)

Advanced Searche changes -- wildcards

The other day the ISFDB server experienced a temporary slowdown. It turns out that it was due to an attempt to retrieve a complete list of ISFDB authors using Advanced Author search. The offending user ran a search on "%", one of our wildcard characters. In order to prevent future performance problems, Advanced Search has been modified to disallow search values which are limited to "%", "*" and "_". Ahasuerus 15:15, 1 November 2018 (EDT)

EditPub and EditTitle -- changing author order

As Template:AllFields:Collaborations states:

  • If a work has multiple authors, it doesn't matter in which order you enter them. The ISFDB does not record author order regardless of how the authors are entered

The order in which authors were entered has always been ignored when filing data into the database. However, Edit Publication and Edit Title used to allow creating submissions which changed author order. It didn't actually do anything when the submission was approved, but it could be misleading.

The software has been updated to make it clear that changing author order doesn't create a meaningful submission. Ahasuerus 21:21, 1 November 2018 (EDT)

Jim McLeod

In the author record for Jim McLeod, is the artist who worked from 1970 to 1988 a different person than the horror reviewer who worked from 2011 to present (and who spells his name "Mcleod")? It seems like a certainty they must be different but I can't actually confirm it. --Vasha (cazadora de tildes) 16:19, 2 November 2018 (EDT)

I think the question should be the other way around. Unless there is something that indicates they are the same (and I'm not seeing it), they should be separated. The time periods and activities are different enough that we shouldn't assume they are the same person. There is nothing about artwork on the provided website link. -- JLaTondre (talk) 16:43, 2 November 2018 (EDT)
I have separated the two. -- JLaTondre (talk) 13:44, 3 November 2018 (EDT)
Thanks, but McLeod (I) should be spelled "Mcleod." --Vasha (cazadora de tildes) 15:46, 3 November 2018 (EDT)
Done. -- JLaTondre (talk) 15:49, 3 November 2018 (EDT)

Canonical name change: John Trevena

I suggest changing John Trevena's canonical name to Ernest G. Henham. It is as commonly found as Trevena (now that I have just added another title as by Henham) and this is the form used in SFE3. --Vasha (cazadora de tildes) 16:57, 2 November 2018 (EDT)

Looks like it was done. ···日本穣 · 投稿 · Talk to Nihonjoe 13:27, 4 November 2018 (EST)

Haunted Houses

Wanted to get some more opinions on a discussion ... it's about a book titled Haunted Houses, for which the publisher's description is "... discusses ten documented cases of ghosts and poltergeists from the past and present and suggests various theories to explain them." I think that it is outside the scope of this DB because it is a nonfiction book about real-life paranormal phenomena; however, the verifier, Auric, argues that it is fiction because "The LC Catalog puts it under 'Ghosts--Juvenile literature'. Also nonfiction is subjective, and depends on whether or not you believe in ghosts." Anyone else? --Vasha (cazadora de tildes) 18:26, 4 November 2018 (EST)

Sorry - jumped in on the conversation instead. The LC (sub)classification of Juvenile literature does not mean fiction. They have biographies sub-classified as such. For this particular title, they have a Dewey Decimal number of 133 which is non-fiction. As to the second argument - is the classification of religion as nonfiction subjective and depends on whether you believe in God? ../Doug H 10:08, 6 November 2018 (EST)
We typically determine whether a work is fiction by examining the way it is presented. Stories like:
  • "I Was Kidnapped and Experimented on by Aliens"
  • "Secrets of Creation as Told by an Angel"
  • "My House Is Haunted"
are considered fiction if they are presented as fictional, i.e. not real, stories. Otherwise they are considered non-fiction. ISFDB:Policy says "Psychic and extrasensory abilities, including but not limited to clairvoyance, levitation, precognition, telekinesis, telepathy and teleportation, when presented as real [are considered speculative fiction]".
We have occasionally run into a couple of issues with this definition. The first one is raised by works which facetiously claim that they are non-fiction. In some cases it's not immediately clear whether the author was being facetious or not. The second one is the publisher using the classic "Truth or Fiction? You Decide!" stunt.
When in doubt, we generally enter the work and add comments. Ahasuerus 12:42, 6 November 2018 (EST)
The phrase that the work "suggests various theories to explain them" does heavily point in the direction of nonfiction: it seems that also non-supernatural explanations are discussed. Stonecreek 00:24, 7 November 2018 (EST)
Are we agreed that this,one should go? --Vasha (cazadora de tildes) 13:29, 17 November 2018 (EST)
Am I misreading something here? The part of the policy, specifically ... when presented as real Ahasuerus cited above actually says to keep it?! MagicUnk 17:42, 17 November 2018 (EST)
The other way around: that's one of the things that is excluded from the DB. --Vasha (cazadora de tildes) 17:54, 17 November 2018 (EST)
No, it is not; it is currently under the inclusion section of the policy. The Haunted Houses case mentioned above is presented as real, so is included. MagicUnk 01:29, 21 November 2018 (EST)
Re-reading the Policy, I think it must be reworded to be clearer; instead of ...when presented as real, it should read ...when presented as if it were real [but is not]. That would correctly convey the intent of the rule, I think. MagicUnk 06:37, 21 November 2018 (EST)
Technically, all bullets in the "Inclusions" section are under "speculative fiction", so they only cover fiction works. However, since the "occult fiction" bullet clarifies that it's limited to fiction, we might as well do the same for "psychic and extrasensory abilities" in order to avoid confusion. I have changed "when presented as real" to "when presented as if they were real" -- thanks! Ahasuerus 12:47, 30 November 2018 (EST)

Amazon image cleanup

The post-submission pages associated with New/Add/Clone/Edit Publication submissions have been enhanced. They now display a warning if an Amazon image URL contains additional formatting like ".SY346."

A new cleanup report has been coded and deployed; the data (approximately 1540 publications) will become available tomorrow morning. The report is available to all editors. At this time the report doesn't support the ability to "ignore" records. If we find Amazon URLs that have legitimate "L._" formatting, we will re-evaluate our options. Ahasuerus 18:47, 5 November 2018 (EST)

Jeanne Cook/Gini Koch

Is there some reason why Gini Koch's canonical name is Jeanne Cook? Are we using her real name to avoid having to choose between her pseudonyms? She uses Koch most often by far, and as for it being better known ... two recent publications were billed as "Gini Koch writing as Anita Ensal" and "Gini Koch writing as A. E. Stanton." --Vasha (cazadora de tildes) 17:08, 6 November 2018 (EST)

IIRC, she used a number of pen names in 2009-2011. It wasn't clear which one (if any) would become dominant, so we used "Jeanne Cook" as a stopgap measure. At this point it's abundantly clear that "Gini Koch" has won the race and should be made the canonical name. Ahasuerus 17:56, 6 November 2018 (EST)
All edits have been submitted --Vasha (cazadora de tildes) 22:45, 7 November 2018 (EST)
All approved and I finished the mopping up. Should be all set. Annie 00:03, 8 November 2018 (EST)
Looks good, thanks --Vasha (cazadora de tildes) 00:16, 8 November 2018 (EST)

External ID Search enhancements

The External ID Search has been enhanced to support the following conditions:

  • is exactly
  • contains
  • does not contain
  • starts with
  • does not start with
  • ends with
  • does not end with

The publication table that it generates is currently limited to the first 300 matching publications for performance reasons. Ahasuerus 20:17, 7 November 2018 (EST)

Thanks! That is very useful in chasing identifiers that were set as the wrong type (for the ones that are not just numbers anyway). Annie 17:30, 8 November 2018 (EST)
The search logic has been further enhanced to redirect to the Publication page if only one matching publication record has been found. Ahasuerus 11:42, 14 November 2018 (EST)

Cleanup reports and invalid HTML lists in notes

The cleanup reports which look for bad HTML in notes have been enhanced to search for "li" tags without corresponding "ul"/"ol" tags. The new data will become available tomorrow morning. Ahasuerus 11:03, 8 November 2018 (EST)

Audio books and page counts

It turns out that we have 3K+ audio books whose page count is set to "0". "0" page counts are not displayed on publication pages or in publication tables, so the problem is currently masked.

Would anyone happen to remember if using "0" for audio books was a conscious decision? I can't find anything relevant in our SourceForge archives. Ahasuerus 11:58, 8 November 2018 (EST)

I seem to remember that at least some of the types were producing a bibliographic error when the field was left as 0 - and some people were adding 0 just to make it stop. Not sure how many of them came this way but that may account for some of them. Annie 17:29, 8 November 2018 (EST)

(unindent) Bug 716 has been created to address the fact that "0" page counts are not displayed. SR 144 has been created to blank out audio books' "0" page counts programmatically. Ahasuerus 14:28, 12 November 2018 (EST)

All 2,423 audio books with "0" page counts have had the field blanked out. We also have 1,432 ebooks and 119 webzine issues with "0" page counts. We may want to consider taking the axe to them as well. Ahasuerus 15:59, 14 November 2018 (EST)

Geoff Brown

For a while horror editor and publisher Geoff Brown used the name "G. N. Braun" on the fiction he wrote; we had that as his canonical name, assuming (I suppose) that fiction would be better known. However, the majority of his web presence and interviews are under the name "Geoff Brown," and this year he started republishing the "Braun" fiction as by "Brown" (two stories so far that I know of). Is it time to change his canonical name yet? I actually was thinking that "Brown" should be the canonical name even before he started republishing the stories, and suggested it a couple years ago. --Vasha (cazadora de tildes) 21:46, 8 November 2018 (EST)

Help currently says that "the canonical name is the most recognized name for that author within the genre". I suppose if a fiction author is "most recognized" as an editor (H. L. Gold, Howard Browne, John W. Campbell, etc), the canonical name would be his "editor" name as opposed to the "fiction author" name. We even use R. S. Richardson as the canonical name (as opposed to Philip Latham, the pseudonym that he used for his fiction) because Richardson was somewhat better known for his non-fiction essays in SF magazines.
In this case I think the case for "Geoff Brown" is strong enough to warrant action. Ahasuerus 13:43, 10 November 2018 (EST)

Newford (de Lint) reading order

I'd like to update the reading order for the Newford series to match the author's recommendation. Do I need reach out the PVers for any affected pubs, or can I just update the titles? Thanks TAWeiss 13:00, 10 November 2018 (EST)

Hm, that's a rather tangled web. Since the stories do not need to be read in a particular order (except for the trilogy mentioned by de Lint), one could argue that the publication order is our best bet. Then again, perhaps putting juvenile and young adult books in a separate sub-series may not be a bad idea. Ditto the horror/thriller books published as by "Samuel M. Key" since they are so different. Decision, decisions... Ahasuerus 14:26, 10 November 2018 (EST)
de Lint's recommendation would line up with the publication order, so I think that should be updated. I don't know whether adding a subseries for YA books makes the listing clearer, but I think making sure that the core books are linked makes sense. Based on my reading, "The Wind in his Heart", probably should be removed, and the three missing books from the author's list should be added to the numbered list. TAWeiss 10:23, 11 November 2018 (EST)
I am all for adding the missing books, of course. Re: "The Wind in His Heart" (2017), this Publishers Weekly review mentions "Leah Hardin, a Newford blogger", so I assume that it's at least set in the same universe. Perhaps de Lint hasn't had a chance to update the FAQ yet? (It's a very common problem with these kinds of lists.) Ahasuerus 12:25, 11 November 2018 (EST)

Possible new option for adding translations

As per this discussion on my Talk page, there is interest in simplifying the process of adding translated publications to existing title records. As JLaTondre wrote a couple of days ago:

We are having a lot of translations being entered now. When the translated title doesn't already exist, it is a two step process to add the new book and then variant the translated title to the original. At the title level, it would be nice to have an "Add Translation to This Title" button which would simply be the "Add New Novel" (or whatever one is the equivalent type as the parent) screen, but it would automatically variant the new container title to the original title.

I have poked around a bit and here is what I think. Suppose we have a title like this one and we want to add a translation. Normally, when you click Add Publication to This Title, the following fields are grayed out:

  • Title
  • Transliterated Title(s)
  • Author(s)
  • Pub Type

The proposed option, which we will tentatively call "Add Translated Publication to This Title", will look the same with the following exceptions:

  • title, transliterated title(s), and author(s) will not be grayed out
  • a new drop-down list, "Language", will be added
  • a new field, "title note", will be added. It will be used to capture the name of the translator(s) and/or any other translation-specific information.

The new data entry form will create a submission which, once approved, will create a new title record using the entered title/transliterated title(s)/author(s)/language/title note. It will also turn the newly created title into a variant of the original title. The new title will inherent the values of the "title flags" from the parent title.

Does this sound about right? Ahasuerus 15:26, 10 November 2018 (EST)

Sounds useful, yes. The form will be the same as Add New Publication except for lacking title flags? --Vasha (cazadora de tildes) 16:03, 10 November 2018 (EST)
It will be a cross between Add New Publication and Add Publication to This Title. Unlike the former, there will be no Synopsis field and no Series fields. We could add a "Web Page" multi-field since Web pages are valid for variant titles. Ahasuerus 16:19, 10 November 2018 (EST)
Yes, please :) MagicUnk 16:59, 10 November 2018 (EST)
This field would really be nice to have. Stonecreek 00:18, 11 November 2018 (EST)
That reminds me ... does anyone have bright ideas for how to not display Content field when editing titles except if they're OMNIBUS? I keep pasting web links in that field by mistake ... --Vasha (cazadora de tildes) 18:00, 10 November 2018 (EST)
The larger issue here is that certain title fields only apply to certain title types. Since the Edit Title form lets you change the values of multiple fields, including the title type value, it can result in inconsistencies. Here are some of the ways in which we currently handle these issues:
  • Disallow changing the title type. This is currently done for REVIEWs and INTERVIEWs because you can't easily convert them to other title types.
  • Gray out certain fields based on the title type. This is currently done for the two Series fields when editing CHAPBOOK titles. It's not a great solution since the fields remain grayed out even after changing the title type.
  • Add pop-up validation to prevent editors from creating invalid records. This is what happens when an editor enters a value in the Content field for a non-OMNIBUS title or a "Length" value for a non-SHORTFICTION title.
  • Cleanup reports. Lots and lots of cleanup reports.
One way to handle this issue would be to make the data entry form logic immediately gray out and "ungray out" relevant fields when the value of the Title Type field is changed. Changing the title type from OMNIBUS to something else would blank and gray out the Content field. Changing it to CHAPBOOK would blank and gray out the two Series field. Etc.
The problem with this approach is that blanking no longer relevant fields becomes a problem if the editor decides to change the title type again. The only way to get the zapped data back would be to hit F5, but then the rest of the new data would disappear. This is the reason why I originally decided to use pop-up validation instead of graying/ungraying fields on the fly. If there is a better way to do this, I will be more than happy to implement it! Ahasuerus 12:17, 11 November 2018 (EST)

(unindent) OK, FR 1222 has been created. Ahasuerus 14:23, 12 November 2018 (EST)

Cleanup reports: "HTML in Notes" tweaked

While working on another requested feature, I noticed that some Notes cleanup reports used incompatible lists of disallowed HTML tags. The lists have been consolidated and streamlined based on what's currently stated in Help:Using Templates and HTML in Note Fields#Supported HTML tags.

Once the nightly reports run overnight, the affected reports will include a few new records which mostly use the "small" tag. It's a harmless tag, so if we decide that it's useful, we can trivially add it to the list of supported tags. Ahasuerus 19:47, 10 November 2018 (EST)

Bug?

Hi Ahasuerus, I just noticed that when I am clicking on the question mark next to the Graphic Format flag of a New Chapbook, I'm redirected to http://www.isfdb.org/wiki/index.php?title=Template:PublicationFields:Graphic, which is empty, instead of to http://www.isfdb.org/wiki/index.php?title=Template:PublicationFields:GraphicFormat. MagicUnk 06:00, 11 November 2018 (EST)

Fixed -- thanks for identifying the problem! Ahasuerus 10:22, 11 November 2018 (EST)

Mirandese Language

The software has been updated to add support for the Mirandese language. Ahasuerus 10:35, 11 November 2018 (EST)

Post-submission warnings -- HTML in notes and titles

Post-submission pages have been enhanced to display yellow warnings for HTML tags within titles and for invalid/mismatched HTML tags in Notes. The code is brand new and doesn't cover every possible permutation, but it's better than nothing. Ahasuerus 18:56, 11 November 2018 (EST)

Something is off when there is some more complicated HTML. this just decided to show me yellow and it is clean. Another one earlier had a similar problem. The change here is swapping a link with a templated OCLC and I checked 3 times that I did not mess up the only line I edited. Not sure what the parser is catching up on - the report never flagged anything and I do not see a problem either...Annie 19:13, 11 November 2018 (EST)
I think I see what the problem is. Let me see if I can fix it real quick. Ahasuerus 19:52, 11 November 2018 (EST)
If the guess is the "a" tags, this confirms it. No other HTML here... Annie 19:53, 11 November 2018 (EST)
Links and tables, basically. Hopefully the patch that I installed a couple of minutes ago took care of them. Ahasuerus 20:09, 11 November 2018 (EST)
Links don't alert anymore - will keep an eye for other anomalities. Thanks for adding this check! Annie 20:15, 11 November 2018 (EST)
Sure thing. No extra charge for the bugs! Ahasuerus 20:46, 11 November 2018 (EST)

(unindent) When you have a chance, can you see why this did not alert about the missing /a and the missing quotes around the href. These are two of the most common issues with html submissions so it will be great if we can see a warning for them. Annie 01:21, 15 November 2018 (EST)

The invalid HTML report does not catch it either (the missing quotes in href did) - so maybe the missing quotes are throwing off the parser - thus neither the report, nor the new warning system sees it. Annie 01:24, 15 November 2018 (EST)
Any ideas here? Annie 13:48, 16 November 2018 (EST)
Sorry, I missed the original question. I'll take a look when I am feeling better. Ahasuerus 15:05, 16 November 2018 (EST)
Sorry, did not want to nag. Feel better. Annie 15:24, 16 November 2018 (EST)
No problem. At the very least the problem needs to be documented. FR 1225 has been created. Ahasuerus 16:08, 16 November 2018 (EST)

Plates?

Concerning The Treasure of the Isle of Mist T2215219, in a 1934 edition not yet in the database (AddPub is now in the queue as "to be continued"). Full view of this publication is available at HathiTrust, presumably because there is no 1934 copyright statement for the new illustrations. The text is pre-1923.

I diagnosed "plates included in the pagination" by reference to the numbered pages. For instance the 4-page span pp. 5-8 --two leaves on the usual use of odd and even numbers-- is represented by unnumbered pages that display a small drawing, a caption, a full-page drawing (listed by that caption in "Illustrations" as page 7), and nothing. See page 7 at HathiTrust, for one point of entry. Probably those are two plates, eh?

But another listed illustration corresponds to a span of 3 unnumbered pages only, pp. 171-173, which display small drawing, caption, and full-page drawing. See page 173. Relying on the usual use of odd and even numbers, one page of the text, p. 174, is printed on the back of that full-page drawing. --Pwendt|talk 19:09, 11 November 2018 (EST)

P.S. The Library of Congress has a record of this edition, LCCN: 34-27187, which reports "plates". That means leaves of distinct paper stock, right? And normally the text is printed on other leaves. (I say "normally" but I have previously taken it for granted as universal.) --Pwendt|talk 19:27, 11 November 2018 (EST)

Alternate Titles field

(copied from R&S) ... [Software improvements could help with ongoing issues]

  • Firstly, adding equivalency of capital/small letters in Cyrillic and other alphabets ... (and while you're at it, improved handling of non-Latin-1 characters in the Roman alphabet too).
  • Secondly, adding the ability to ignore punctuation when searching and checking for duplicates.
  • Thirdly (perhaps as a stopgap in place of the other two suggestions), following up on a suggestion which was made some while ago, to add a field for alternate titles which differ only in punctuation or accents; the alternate titles in this field wouldn't be displayed (they wouldn't be mouseover text like transliterations are) but would help with searching.

--Vasha (cazadora de tildes) 15:49, 11 November 2018 (EST)

Re: "adding equivalency of capital/small letters in Cyrillic and other alphabets", it's certainly desirable and important. However, it's not really "adding functionality", it's "upgrading/replacing the database engine". Think of it as replacing a gasoline engine with a diesel engine: doable but time-consuming and but has all kinds of ramifications for the vehicle. Given my other current responsibilities (Fixer, maintenance, e-mail communications with 3rd parties like SFE3 and MIT, Wiki, etc) and my less than stellar health/energy/ability to learn new things these days, big projects like that are a steep hill to climb. We could really use another developer or two. During the summer I helped a volunteer set up a separate development server, but I haven't heard back from him in a few months. I have other prospects as well, but nothing definite at the moment. Of course, a number of our active editors have development backgrounds, but for some reason they seem to be unwilling to quit their day jobs and concentrate on ISFDB development. Most peculiar! (Fixer tells me that it may have something to do with the rumor that humans like to eat.)
Re: "the ability to ignore punctuation when searching and checking for duplicates", the main Duplicate Finder has three modes: Exact, Similar and Aggressive. The last two ignore punctuation. On the searching side, I experimented with different approaches a few months ago, but it turned out to be significantly more complicated that I had expected. Apparently, the guys at Google are well paid for a reason... Ahasuerus 16:30, 12 November 2018 (EST)
Yes, I remember you've said before that these things aren't really feasible without some change in circumstances (like additional developers). Sorry for bringing them up again. But since real improvements are far off, what do people think of adding a field for this sort of variant titles? We are currently using the transliteration field for the purpose, but it's not the best practice to mix two kinds of data in the same field. --Vasha (cazadora de tildes) 16:49, 12 November 2018 (EST)
Agree re: "it's not the best practice to mix two kinds of data in the same field". The issue has been raised in the past, but no FR has been created (that I recall.) The proposed functionality, as I understand it, would be a subset of the functionality supported by Field 246, "Varying Form of Title", which exists to record "alternative form[s] of the title" in the MARC 21 standard. The linked Web page includes various examples. If you would like to pursue this line of thought, we may want to move the discussion to the Community Portal. Ahasuerus 20:39, 12 November 2018 (EST)

(unindent) The proposal is to add a field for the purpose of collecting together minor variations in the title (or other author name, etc.) which currently cause the software to not recognize them as the same title (author). Namely, things like non-Latin1 characters (people need to be able to find Helen Oyeyemi's story "Dornička and the St. Martin's Day Goose" even if they type "Dornicka"), and minor differences in punctuation like whether there is or is not an Oxford comma. There are also existing instances in this database of the Transliterated Title field being used to store other types of variation that are on the MARC 21 page Ahasuerus linked, such as entering "One Hundred Cats" as an alternate to "100 Cats." The proposed new field would never be visible to users (it wouldn't be mouseover text like transliterations are), but it would be used by the software in searching.

This would be just an ad-hoc thing as a stopgap until (at whatever future time) the software is improved. People would simply enter whatever variants they can think of. We have already put some of that into the transliteration field; it would be a moderate-size cleanup project to move it to the new field and leave Transliterated Title for just transliterations from one alphabet to another. --Vasha (cazadora de tildes) 21:45, 12 November 2018 (EST)

Easier solution is to use Google. Add a new search option on the Advanced Search that uses a Google search with predefined syntax that limits the search to ISFDB and with specific words (Title, Publication, Summary Bibliography, Publication, etc.) in the page title. For the Dornicka example, site:www.isfdb.org intitle:title Dornicka will search only ISFDB for pages that have Title in their title (i.e. title records), and matches Dornicka which correctly returns "Dornička and the St. Martin's Day Goose" (try it). It would consist of a single pull down to select page type and a text box. That would be a lot easier than adding new fields (which need to be added to the database, multiple forms, search options, etc.) and also then need to be populated. Search engines are great at fuzzy matches so let them do their thing vs. recreating it in a much less ideal way. It will search the whole page, not just a particular field, which can either be a downside or a plus depending on your goal. -- JLaTondre (talk) 07:35, 13 November 2018 (EST)
It would be easy to add a "Google Search" option to Advanced Search. We could even add a context-sensitive "Google Search" check mark to the main search box. (The reason it would have to be context-sensitive is because a Google search on "Year of Title = 1872" wouldn't work too well.)
However, keep in mind that Google's data is typically a few weeks behind, so it won't find any recently added/changed data.
I am thinking that the low-hanging fruit would be to add a "Google Search" section to Advanced Search, which can be done quickly, and see what happens. Ahasuerus 08:26, 13 November 2018 (EST)
Yes, Google search isn't the ideal solution. However, I think it's better than the suggested interim solution given the trade between work & benefit. Though my over all preference would be doing neither since there is other work I'd personally rate higher. So maybe I'm biased. ;-) -- JLaTondre (talk) 11:35, 13 November 2018 (EST)
That'd help. But would it allow the stuff that doesn't belong in the transliteration field to be removed, or would we still need that? There's an existing cleanup report that mandates entering an alternative to non-Latin1 characters --Vasha (cazadora de tildes) 12:26, 13 November 2018 (EST)
Well, if you work with Cyrillic titles, you may have a different bias - try to look for an author called Вежинов and then вежинов. :) For example. Now think about how often people hit caps lock or shift by mistake :) Another option is to use the transliterated fields to contain a "lower case only" version of the name amongst the other transliterations and add an explanation to the advanced search (and on the result screens) on how to search in case you cannot find what you are looking for). Thus NO real work (besides a few comments in the search pages) as we already search the transliterations by default. That would be similar to transliterating the kanji in kana for Japanese. Not elegant but... good enough stopgap until we can swap the encoding. And once it is swapped one day, deleting these will be easy (as they will match without case to the main title). And it is similar to the whole alternative title thing... (at least for the search problems) minus the work. Plus there is a case to be made that going to all smalls is a type of transliteration (from an alphabet of A-Za-z to one with a-z) :) Annie 12:32, 13 November 2018 (EST)
Uh, no, that is not a transliteration. Someday (hopefully) we are going to have a real solution to the problem of fuzzy searches/capitals in Cyrillic/etc. and then the transliteration field will just be for one alphabet to another (one writing system to another, in the case of kanji-to-hiragana). Why shouldn't we start now with the process of cleaning up that field, putting everything that is not a transliteration into a different field? We have thousands of titles currently where the lowercase version or non-latin1 character or whatever is in the transliteration field, and it would take a few days to go through and move them all; in five years we will have many more thousands—why not enter them into a different field to start with, instead of putting them in the transliteration field where they will eventually have to be removed? --Vasha (cazadora de tildes) 13:13, 13 November 2018 (EST)
Because I would rather have non-transliteration there than spend 2 (or 5) more years waiting for this DB to become even remotely usable for the titles in my native language. And as they will be exact matches (minus letter size), they will be easy to remove when we have that fixed - so we are not facing a long project pulling them out. Let's be realistic here, shall we? Great ideas and what's not is great BUT spending time to build a solution that will be obsolete when we change encoding is worse than dealing with some additional values in some fields. And dumping all kinds of stuff in a new field would not solve the problem - it will just move it to a new field (what goes there? Small letters ones, kana ones for Japanese? Something else? Everything that is not a transliteration?) Call me pragmatic if you want but I would rather not stress the single developer with something that we live without and where we have a soft solution that does not really degrade the data. Annie 13:29, 13 November 2018 (EST)
"We have thousands of titles currently where the lowercase version or non-latin1 character or whatever is in the transliteration field" - huh? Noone had added "lowercase" specifically anywhere so I am not sure what you are talking about? Annie 13:29, 13 November 2018 (EST)
"Transliteration" has a pretty concrete definition. It is taking a word written in one writing system and coming up with an equivalent in a different writing system. Yes, writing the sounds represented by a kanji character as hiragana is a type of transliteration. I am arguing that the Transliterated Title field should only be used for transliterations in this sense. Up to now, we have needed a place to store ad-hoc typographic information like the fact that people may search for "č" by typing "c" or the fact that French "œ" is a typographic variant of "oe," and we have put it into the transliteration field, but it isn't the same type of data and shouldn't go there. --Vasha (cazadora de tildes) 13:40, 13 November 2018 (EST)
Your claim is that NOW we have "small letters" being added to fields - see what I cited from your post. That's the part I am asking about. Because it is not true - we do not use the field this way now. Even if that would have made the DB usable. I know what transliteration is - both from the Linguistics side and from the Math/IT side. As for what is a valid transliteration - A-Zaz -> a-z is writing the same title in a new "set of characters". Not in the linguistics sense but then a lot of things are not. And œ/oe and Б/б are comparable. Just because the letters set is in the same alphabet does not make it less of a transliteration. Technically speaking. :) And again - moving all that "stuff" to a new field does not solve the issue - it just moves it to a new field. Or are we going to keep adding fields ad-infinitum? Annie 14:44, 13 November 2018 (EST)
But anyway - the point I am trying to make is that building a solution that will be obsolete soon does not make sense - when we can just reuse what we have. It does not matter if it is "clean", in both cases we will need to deal with it once the real solution is in place. Add effort, time to execute and all that and as much as I like clean solutions, I would take any solution at this point. Annie 14:56, 13 November 2018 (EST)

Types of Alternate Titles/Values

Let me take a step back and try to list the different types of "alternate titles/values" that we are discussing here. (I prefer "values" to "titles" because the discussion also includes authors, publishers, etc.)

First, here are the scenarios that are currently supported by our implementation of "transliterated values":

  • Romanized versions of non-Latin values. The current implementation supports multiple versions per original value, e.g. "Arifureta Shokugyō de Sekai Saikyō 1" as well as "Arifureta Shokugyou de Sekai Saikyou 1" for "ありふれた職業で世界最強 1".
  • For languages which use multiple alphabets/scripts/writing systems, version(s) of the original title which use alternate systems, e.g. "ありふれたしょくぎょうでせかいさいきょう 1" for "ありふれた職業で世界最強 1".
  • English versions of Latin titles which use non-English letters, e.g. "Dornicka" for "Dornička" and typographic variants like "œ"/"oe"

Next, here are the new types of alternate values which are being proposed, either to be entered in the requested new field or as additions to the list above:

  • Lower case versions of non-Latin values to help with searches
  • Alternative forms of the original value like "One Hundred Cats" as an alternate to "100 Cats". It could include other alternative values like the titles found on book covers and spines which we currently enter in Notes (or omit.)

Re: lower case versions of non-Latin values, I think it will only get us so far whether we enter them in the existing Transliterated Values fields or in the requested new field. Adding "павел вежинов" to "Павел Вежинов" won't help users who type "ПАВЕЛ ВЕЖИНОВ". Without full Unicode support, it will remain a band-aid.

Re: alternative values like "One Hundred Cats", it's been discussed a few times. I don't recall any objections, but it appeared to be a low priority. Also, it will remain a valid separate request even after the upgrade to Unicode. If we can reach consensus re: its desirability, I would be in favor of adding it as a separate FR.

Am I missing anything? Ahasuerus 17:05, 13 November 2018 (EST)

Punctuation is mIssing. Right now typing "X - Y" into the search box won't find "X—Y" and vice versa, nor will "X, Y, and Z" match "X, Y and Z." Plus we had a debate a while ago as to whether it was acceptable to use the transliteration field to enter "X and Y" as an alternative if "X & Y" is printed in the book (who can remember which form to search for?). Finally, I don't agree that typographic matters like c/č and œ/oe properly belong in the transliteration field. --Vasha (cazadora de tildes) 17:25, 13 November 2018 (EST)
So what do you call the č -> c (or ch) transition? It is converting Unicode/ to Latin1 which is the definition of transliteration in the IT world. Looking at the linguistics level, it is a transliteration between two Latin standards (in the same way in which Э э get changed to an existing letter in the alphabets that do not have it; or й between the Cyrillic standards)... But the main question still stand - how adding a new field that contains all that funny stuff will be helpful at all and not just moving the problem from one field to another. Just so it is not in the transliterated field? What is the difference? Maybe we should revisit why we have transliterations to start with - assisting reading from non-native editors and users and facilitating search for users that do not have the proper keyboard to create the special characters (or copying from a source that does not have the correct characters when searching). Or is the second not part of why we have the field anymore? :) Annie 17:43, 13 November 2018 (EST)

(Unindent) OK, instead of arguing about what is or is not a transliteration, and what can or can not go in the "Transliterated Title" Field, how about we rename that field to "Alternate Form of Title"? And agree that you can enter anything into that field if you think it'll be helpful? That'll make sense of all the diverse stuff that already is in it. --Vasha (cazadora de tildes) 18:09, 13 November 2018 (EST)

I think the first step would be to update Help with a list of everything that this field currently supports. After all, there are things that are disallowed at this time, e.g. alternative forms of the main title like the "One Hundred Cats" example above and transliterations that use non-Latin non-native alphabets/scripts. Having the current practices explained in one place (a new Help template, I assume) would get all of us on the same page. With the current rules codified, we would be in a better position to decide whether to:
  • rename the field
  • expand its remit
  • do something else
Ahasuerus 12:49, 14 November 2018 (EST)
Results of a survey of current ways this field is used with titles whose language is English--Besides giving alternatives for non-Latin1 characters, there are the following sorts of uses:
1. Giving text equivalents of titles with symbolical or mathematical elements in them. There are about 50 of these I think; here are a selection:
Rendezvous 10¹⁰   |   Rendezvous 10 to the power 10
eʰ   |   e^h
Golem¹⁰⁰   |   Golem 100
⁵Limericks   |   5 Limericks
X ≠ Y   |   X does not equal Y
∞°   |   Infinity Degrees
The World of Ā   |   The World of A   |   The World of Null-A
fan•dom (fan´ dəm) n. a way of life   |   fandom (fandum) n. a way of life
&#x25CD;   |   "Circle with Vertical Fill" Hex code
♋   |   Cancer
*   |   asterisk   |   star
█████   |   {black bar}   |   [redacted]   |   redacted
Press Enter ▮   |   Press Enter []
<3/</3   |   less than three slash less than slash three
Foreword ((1⁴+2⁴+3⁴+4⁴+5⁴)+6⁴+7⁴)   |   Foreword ((1(to the 4th degree)+2(to the 4th degree)+3(to the 4th degree)+4(to the 4th degree)+5(to the 4th degree))+6(to the 4th degree)+7(to the 4th degree))
2. Giving "and" as an equivalent to &. Done 33 times with the "and" in the main title, & in the transliteration; twice the other way around.
3. Giving "plain" equivalents of titles that are written oddly. For example,
Channel Sk1n   |   Channel Skin
βoyfriend   |   Boyfriend
4. Multiple attempts at writing titles that cannot be entered the way they are in the book. Here is one I did myself: I represented "How Can I Help Hurt You?" as "How Can I Hurt You?" and "How Can I Help Hurt You?"
5. Punctuation variants (these are pretty rare). A selection of examples:
Perce Rock ▬ First Sighting   |   Perce Rock — First Sighting   |   Perce Rock - First Sighting
Little Green Men—Attack!   |   Little Green Men Attack
Never Fear: The Apocalypse   |   Never Fear—The Apocalypse
Interstellar Navigation, or Getting Where You Want to Go and Back Again (in One Piece)      |      Interstellar Navigation; or, Getting Where You Want to Go and Back Again (in One Piece)
6. Just plain alternate titles.
SciFan™ Magazine - 2017   |   SciFan Magazine - 2017
[a cover art title] Jump Point, Issue 02.03   |   Warned
The first of these categories, at least, seems pretty firmly within the existing mission of the field (the others may be extensions of the mission, and number 6 flat-out wrong). But "Alternate Writing of Title" or some such name seems to describe those text-equivalents better than "Transliteration." --Vasha (cazadora de tildes) 15:26, 14 November 2018 (EST)
Why isn't "™" in the first category? This is a special symbol, not two letters with weird formatting (in that writing anyway). Not much different from some of the others in category 1. I would not call that alternative writing - it contains a symbol that people may not be able to create... Just because it looks like letters does not make it letters really - not in a title. Annie 15:46, 14 November 2018 (EST)
Because SciFan Magazine is sometimes written with the TM and sometimes without, and I think this was intended as a way of putting both names in the same record. We should figure out which is the "real" title and/or make them variants of each other. (Not that easy because SciFan Magazine is now defunct and out of print, but ...) --Vasha (cazadora de tildes) 16:01, 14 November 2018 (EST)
It occurs to me: "and" is a text-equivalent of "&" so that one, at least, makes sense in the existing conception of the field. --Vasha (cazadora de tildes) 16:20, 14 November 2018 (EST)

(unindent) Attempt at codifying the use of this field (whatever it's called). Currently, it is chiefly for: 1. Transliterations from one writing system to another. 2. Providing Latin1 alternatives to non-Latin1 characters. 3. Spelling out mathematical expressions and symbols in words.

Proposal: As a logical extension of use no. 3, I would like it to be specified that it's acceptable use this field to spell out "&" as "and." Second proposal: spelling out numbers in words; this is also a logical extension of use no. 3.

Other possible uses: spelling out abbreviations? (e.g. vs./versus)? I'm undecided but I think maybe not.

We also have a few quirky miscellaneous uses at present, like the strikethrough example and the Channel Sk1n/Channel Skin example above. There are only a few of these, I don't see a better way to handle them, and as far as I'm concerned they can be left as is, ignored & not mentioned in the codification of the uses of the field.

It seems that this field should NOT be used for variant punctuation. The proposed Google search will take care of it instead (and much better).

Any thoughts on additions/subtractions to this list of uses? I think we are almost ready to write up a description of the field, and then we can debate its name. --Vasha (cazadora de tildes) 01:23, 16 November 2018 (EST)

Any further thoughts on this? --Vasha (cazadora de tildes) 16:27, 24 November 2018 (EST)
Thanks for researching the current patterns of use. One thing that comes to mind is that the proposed Google search functionality may also take care of certain other types of cases like "&" vs "and". It may be better to implement Google search first, see how much we can squeeze out of it, and then revisit this field. Ahasuerus 12:15, 27 November 2018 (EST)
It is true that Google can handle &/"and." But an argument in favor of entering the alternate text anyway (in just this one case) is the same as the argument in favor of keeping the Latin1-alternative uses of the field: why force people to switch to Google if you have a simple way of getting the direct search to find the desired result? The "and" situation is common (and annoying) and adding alternative text for it would be relatively easy. I don't think we should go hog-wild entering alternative text for all symbols, though. --Vasha (cazadora de tildes) 16:22, 27 November 2018 (EST)
Vasha, I saw you adding one of the &/and today. Let's wait a bit before we start changing things until we agree what we want to do. As annoying as it may be to you, just going ahead and doing something that may need reversal is losing everyone's time in the long run - and makes the DB even less consistent than it is. So let's agree first, then change in whatever direction we agree on. I know it is annoying and we all would love to have things happen faster but everyone doing what they want is not the path forward. :)
I would support adding & as one of the values that makes sense BUT... what about the other direction? Do we really want to add the opposite one for people that may search with &? I do not think so. So if it is one-directional, we need to make some notes on the result page around that. Annie 16:27, 27 November 2018 (EST)
I can think of a few additional issues with "and/&". For example, what should we do about non-English titles/values which use "&"? Should we use "und", "et", "en", "e", "y", etc depending on the language? Also, what should we do if there are multiple ampersands, e.g. "Linda & Daniel & Spike" or "Romeo & Julia — Innenansichten von Adam & Eva 2.0" or even "Filomena & Greg & Rikki-Tikki & Barlow & the Alien"? Ahasuerus 17:15, 27 November 2018 (EST)
Yeah, that's a good point... and then the other direction, combined with languages and what's not, gets even muddier. Thus my point - let's first figure out what we are doing before we start doing it :) Nothing is easy when you try to do fuzzy searches by hard-coding values... And that one may be solvable in a different way actually - less manual (details to follow when I work through them in my head). Annie 17:45, 27 November 2018 (EST)

Narrator Template

Can we add a Narrator template for publication notes? That will make it easier to find the books we have that are narrated/read by a certain person (and one day when we have "non-authors connected to books" fields, we can migrate easily. Annie 22:50, 12 November 2018 (EST)

It would be easy to add a new template for narrators assuming that the functionality is similar to that of the "Translator" template. Ahasuerus 08:53, 13 November 2018 (EST)
Yep, same idea. :) Annie 12:13, 13 November 2018 (EST)
What should we call it then? "Narrator"? Something shorter along the lines of "Tr"? Ahasuerus 15:35, 13 November 2018 (EST)
Narrator sounds good to me. Tr made sense but I cannot figure out how to make Narrator shorter without making it too cryptic :) "Reader" also works for me - although it should still be "Narrated by X" when on the page. Or maybe "Narrated/Read by X"... Annie 15:39, 13 November 2018 (EST)
Too long to type. Why not {{narr|...}}? MagicUnk 16:34, 13 November 2018 (EST)
Too cryptic if you ask me... But I can live with narr. Or maybe "read"? Annie 16:50, 13 November 2018 (EST)
Wellll, you could say that of "Tr" too. But once you know what it is, you won't forget. Narr has an advantage over read in that narr == narrated is easier to remember than read == narrator. MagicUnk 17:19, 13 November 2018 (EST)
"Tr. by X" is a standard bibliographical entry though :) Older books called those "readers", now the modern term is "narrator" although some books still say "read by". So they are interchangeable. So for some people the term is reader and not narrator so "narr" will be absolutely undecipherable. I can work with either - and we can always change if needed Annie 17:30, 13 November 2018 (EST)
I expect that "read" would be less intuitive than "narrator". Also, since I don't use audio books, I would probably find it hard to remember that "narr" stands for "narrator", but perhaps I would get used to it. Ahasuerus 12:33, 14 November 2018 (EST)
I still think that the one that will the least confusing is "Narrator" :) Annie 13:48, 14 November 2018 (EST)
That would be fine by me. Ahasuerus 15:00, 14 November 2018 (EST)
Sure, can live with that :) MagicUnk 16:59, 14 November 2018 (EST)

Narrator Template - Outcome

FR 1224 has been created. Ahasuerus 10:07, 15 November 2018 (EST)

Length for Audiobooks

On a related note, how long a book runs is comparable to page numbers. So should we add a new field to collect this information (audiobooks are more and more popular) or should we start using the "pages" field instead (as these will never have pages). I am more inclined to go for a new field (two separate pieces of data in the same field is a bad idea) but in this case as a book is either a paper one or an audio one, they are separate enough (and ebooks stay with the current policy of "no number of pages")Annie 22:50, 12 November 2018 (EST)

If a new field is added, it would be best if the software was smart enough to only display the correct field for the type of pub (i.e. physical books should page number, ebooks show nothing, and audio books show length) instead of always showing them. Or at least only make the correct one editable. Requires the edit form to be a bit smart as have to update the display when the format is changed while editing. -- JLaTondre (talk) 07:18, 13 November 2018 (EST)
I discussed some of the issues with dynamically changing the data based on the title/publication type here. Ahasuerus 08:33, 13 November 2018 (EST)
Field state (active/inactive, displayed/hidden) can be changed dynamically via JavaScript. Here is an example that displays a field when one option is chosen but not another. The value is not lost when hidden (in the example, change it to "Business use", enter text, change it to a different state, and the change it back). On the back-end, the submission logic would need to handle the fact there is a no longer needed value and toss it out. -- JLaTondre (talk) 09:18, 13 November 2018 (EST)
How about the same logic we use for "series" in variants? Annie 12:13, 13 November 2018 (EST)
That doesn't work the reasons Ahasuerus laid out in his above link. It works for series because you cannot make a variant a non-variant from the title edit screen. -- JLaTondre (talk) 12:45, 13 November 2018 (EST)
Yeah, missed that one when reading this morning. Oh well... I am not sure what is the problem with just having both and having editors just be careful plus a nightly report that finds values in the wrong field. Considering all the other problematic fields, that one is not even that challenging. I would love a software solution but if there isn't one that works across browsers and what's not, we can live with it :) Annie 14:47, 13 November 2018 (EST)
We could add pop-up validation that would disallow "length" values for non-audio formats, but first we would have to decide what to do with combined "paperback+CD" publications. Ahasuerus 08:33, 13 November 2018 (EST)
Any thoughts re: "paperback+audio" publications? I believe I have only one in my collection, but they have apparently become more popular lately. Their records should presumably allow both types of values. Ahasuerus 15:41, 13 November 2018 (EST)
Allow both fields to be populated for that case specifically. That should not be a problem, right? Annie 16:30, 13 November 2018 (EST)
There's an issue with adding fields at the front end: clutters the screen, losing oversight. Therefore, "smart" forms are the way to go. MagicUnk 16:55, 13 November 2018 (EST)
This is the part that I am not sure about. Back when we added context-sensitive drop-down lists to the Advanced Search page, some users commented that they didn't understand why values were changing as if by magic. I am concerned that dynamically adding and deleting fields based on the values of certain other fields (like the publication type field) would be even more confusing. Ahasuerus 12:40, 14 November 2018 (EST)
Really? Once upon a time I had something done very similar with an application I defined the functionality for (ie dynamically updating labels dependent on certain type values), and no-one ever complained that was confusing. Au contraire, I definitely got the impression they really ignored it altogether... MagicUnk 16:54, 14 November 2018 (EST)
A lot can depend on the user community, including things like their computer savvy, whether they are occasional users or regular users, etc. Ahasuerus 10:06, 15 November 2018 (EST)
(Adding more fields to the database isn't an issue. In fact, on DB level fields should never be used for multiple purposes). There's another way of dealing with using a single input field for two different value types: change the label only, and when saving, the backend logic determines in which field to save the entered data, dependent on title type. Only one field needed, so no keeping track of previously-entered data when switching type.That approach doesn't support the pb+audio though, but it might be useful approach somewhere else... MagicUnk 16:55, 13 November 2018 (EST)
Which is where I started - reuse the field we have now. Technically pb+audio is not different from a boxset where we do 300+300+300 for example... as long as we know what is first :) New field will make it less confusing for new editors BUT more convoluted for us (what do we show on pub lists under a title for example)? Annie 17:27, 13 November 2018 (EST)
Not sure we were actually saying the same; there's a distinction to be made between adding additional fields on the forms (and hence to the DB as well) - which is what you were proposing if I understood correctly?, as opposed to keeping the UI slick, keep changes and additions to a bare minimum, and only expanding the DB tables with additional attributes. MagicUnk 16:57, 14 November 2018 (EST)
My initial note had two proposals - keep one field for both (type determines what it means) or add a new one. How the DB is designed behind that is irrelevant really - and if we have a single field, doing separate DB fields and from there separate search options will be confusing (and can have performance considerations if someone tries to do a query weirdly) so if we stay in one field, we should just stay in one field if you ask me. :) Annie 19:39, 14 November 2018 (EST)

Changing data entry forms dynamically -- options

I have been thinking about JLaTondre's response above and, more generally, the options that we have when data entry forms end up with internally inconsistent data: CHAPBOOKs with Series data, non-OMNIBUS titles with "Content" data, and so on.

I will first list the options that I was aware of when I was writing this comment:

  1. Disallow changing the values of certain key fields to avoid inconsistencies. This is currently done in Edit Title for REVIEWs and INTERVIEWs: you can't easily convert them to other title types.
  2. Gray out certain fields based on changes to key fields like "title type". This is currently done for the two Series fields when editing CHAPBOOK titles. It's not a great solution since the fields remain grayed out even after changing the title type.
  3. Add pop-up validation to prevent editors from creating invalid records. This is what happens when an editor enters a value in the Content field for a non-OMNIBUS title or a "Length" value for a non-SHORTFICTION title.
  4. Dynamically gray out and blank affected fields whenever changes to other fields make them invalid, e.g. Series fields for CHAPBOOK titles. The problem with this approach is that blanking no longer relevant fields becomes a problem if the changes that prompted the blanking are reverted.
  5. Cleanup reports. Lots and lots of cleanup reports.

In addition, we have the following options when "key" values are changed:

  1. Dynamically gray out the affected fields, but do not delete their data. That way if the changes to "key" fields are reverted, "ungraying" the affected fields will restore their data. The problem with this approach is that it may confuse editors who won't understand what "grayed out" data means and whether it will be filed into the database upon submission approval.
  2. Make the affected fields invisible; if the "key" changes are reverted, make them visible again. Would new editors find disappearing fields confusing?
  3. Dynamically gray out the affected fields, delete their data and save it within the browser (probably using a hidden field, which is what we do in Advanced Search.) If the "key" changes are reverted, use the saved data to restore the affected fields' values.

From a purely technical perspective, it's all doable. Functionally, I think I prefer pop-up validation to the "gray-out"/"invisible" options. I suspect that (but can't be sure) changing the form layout and/or the field status dynamically has the potential to confuse new editors. Ahasuerus 16:19, 13 November 2018 (EST)

I am fine with popups. Annie 16:48, 13 November 2018 (EST)

Autobiographical titles acquisition

For our spec-fic authors, which of their publications about themselves should we include in the database? Any threshold on the author should be lower than that certain threshold (ISFDB:Policy#Included, point 4) over which all publications should be included.

For instance, in 1936 newspapers I find coverage of the new book A Long Retrospect as the autobiography of F. Anstey --see LCCN: 36-21029 and ASIN: B000857ECY at Amazon UK. And I find notice that Laurence Housman has nearly completed his own autobiography --not pursued.

One issue here is routine acquisition from secondary sources, as many works mentioned in SFE3 and The Encyclopedia of Fantasy biographical entries are routinely added. Knowing that the book is by Anstey about Anstey, say. Let me stop here. --Pwendt|talk 16:44, 13 November 2018 (EST)

I don't think we have a separate threshold for autobiographies of primarily non-genre authors. That said, as a collector of all things Anstey, I understand where you are coming from. He wrote a fair amount of notable speculative fiction starting with Vice Versa, a minor classic of the genre. Tourmalin's Time Cheques was an early time travel novel which preceded Wells's The Time Machine, etc. Even though we currently don't include his non-genre works, I agree that his autobiography should be included.
At the same time, I am not really sure how we could address this issue at the Policy level. Adding a new threshold for autobiographies would likely only complicate things, especially considering the nebulous nature of the current "certain threshold" for non-genre works. Perhaps we could include autobiographies as "books ABOUT speculative fiction"? Ahasuerus 12:26, 14 November 2018 (EST)

Question about Connection Security

HELP! I have joined ISFDB only on a temp basis because "The Connection is not Secure" is the WARNING I get when entering my Password. I tried using https:// before the URL, but this fails. And I searched high and low for a Contact Us address, but there is none! Only way to get this message to you was to join as a temporary member, pending improved security. Please advise, before the Russians start messing with my account... —The preceding unsigned comment was added by Temp Insecure‎ (talk • contribs) .

Answered on the user's Talk page. Ahasuerus 19:35, 13 November 2018 (EST)

Author names alphabetized

The way co-author names are displayed has been changed. In the past their order was random. Now they are displayed alphabetically based on their respective directory entries (typically family names) and the working names. If you come across any discrepancies, please post them here. Ahasuerus 20:33, 13 November 2018 (EST)

I don't understand "respective directory entries (typically family names) and the working names" and I may miss the point entirely.
Is this true for Title records only?
Selected title listings for series Gulliver's Travels:
  • Variant: The Wonderful Voyages of Gulliver (1909) [as by Jonathan Swift and Edith L. Elias]
  • Gulliver in Giantland (1907) [SF] by Jonathan Swift and Edith Robarts [only as by Edith Robarts and Jonathan Swift, D.D.]
  • The Adventures of Gulliver (1954) [SF] by Jonathan Swift and E. E. Ellsworth
  • Gulliver's Travels (1987) [SF] by Jonathan Swift and D. K. Swan and Michael West (II)
Those co-authors (commonly if not always, Swift and one or two who adapted or retold his work) are not listed alphabetically by family names. Spot check of author records shows correct directory entries such as "Swift" for Swift, D.D. and "West" for West (II).
In the latter case, with three co-authors listed non-alphabetically, the bibliography for author Michael West (II) lists twice, as chapbook and short fiction:
  • Gulliver's Travels (1987) with Jonathan Swift and D. K. Swan
There West's two co-authors are out of sequence, same as in the title listing as displayed for the series. --Pwendt|talk 17:19, 29 November 2018 (EST)
It looks like there are still display bugs on Series and Summary pages. Thanks for reporting them! Ahasuerus 17:40, 29 November 2018 (EST)
Series and Summary pages have been changed to display author names alphabetically. If you come across any other bugs, please post them here. Ahasuerus 19:55, 9 December 2018 (EST)

Title case cleanup - how?

(copied over from R&S): For the Dutch titles - and likely for other languages too - almost all titles hitherto entered in the DB follow the English capitalization rules. Now that we have made it clear language-specific capitalization rules are to be followed, titles need to be updated. What would be the best approach? Can we automate/manual excercise, cleanup reports,...? MagicUnk 17:30, 14 November 2018 (EST)

It is possible to create language-specific cleanup reports to look for titles with second/third/etc words capitalized. I expect that there will be a lot of false positives, so they'll need the "ignore" functionality from the get-go. Ahasuerus 18:29, 14 November 2018 (EST)
Would it work having a nightly job that automatically converts pub titles to the title title's case? Would be great not having to go through both title and pub titles. MagicUnk 02:21, 15 November 2018 (EST)
Originally, there was no requirement for publication titles to match the titles of their respective "reference titles". In fact, we had somewhat different data entry rules for them. However, the rules have been converging over the last few years. We also have a cleanup report which looks for significant discrepancies between publication titles and their reference titles. At the rate things are going, we may want to consider enforcing consistency in the foreseeable future. For now, though, they can be different.
In addition, any kind of automated processing that changes ISFDB records without human supervision is potentially dangerous. We don't have anything like that in place at this time. Ahasuerus 09:56, 15 November 2018 (EST)
As I recall, French and Russian titles have been using "sentence case" for a long time, so they should be in pretty good shape. I am not sure about other languages. I guess we could start by contacting the editors who have been working on major European languages to get a better idea of what the scope of the project(s) is likely to be. (And I see that Annie has already made a similar suggestion on the R&S page.) Ahasuerus 18:29, 14 November 2018 (EST)
From my OCLC cleanup and the language assignment one before that, French, German and Russian are indeed in a relatively good shape. Dutch is not looking too bad although it is a bit worse than the other 3 - there are a lot of titles with the wrong capitalization but from what I had seen a lot more that are added correctly. Spanish is a mixed bag (although I had seen a lot of updates going through), Italian is right there with it and Portuguese will give us a headache. The Western Slavic languages and Hungarian are mostly in the proper sentence case; so are Serbian, Romanian, Finnish and the Scandinavian ones. Bulgarian is clean :). Greek may be a bit of a challenge; the smaller ones should be easy enough to vet even if we go title by title. So as long as we decide on the rules, we may learn more.
Re. Dutch not too bad: I'm afraid that's not true. I did a search, and for the first few hundred results, all needed correction to sentence case.
The first hundred are stories with special characters and what's not which are relatively old records. It gets a lot better downstream - somewhere along the line Dutch editors started using the proper case. Although due to the volume of records, there may be more than expected... :) although looking a bit more into these, Dutch may need reclassification indeed - not sure which language I was thinking of. Oh well. That will be a very long project. Annie 02:43, 15 November 2018 (EST)
But point still stands - we need first to agree on the rules for a language before we start changing things in that language. Annie 18:54, 14 November 2018 (EST)
I'm confused?! Didn't we already agree on the case rule for Dutch? - true, not yet for punctuation but that shouldn't prevent us from cleaning up the ones that have no issue with punctuation. Or am I missing something here? MagicUnk 02:12, 15 November 2018 (EST)
You telling us that is the rules on a page is not an agreement - especially in a language we have multiple editors. Get the other editors to agree, we get closer. And when the official rules are changed, it is considered agreed on. Annie 02:43, 15 November 2018 (EST)
Btw, I'm asking because I'm going through a lot of Dutch titles atm. MagicUnk 02:18, 15 November 2018 (EST)
Then leave a few messages around so we can get the rules locked down? Annie 02:43, 15 November 2018 (EST)
Yes, let's get those rules locked down. We have agreed to language-specific capitalization, but we haven't touched punctuation. Seems like we really ought to talk about punctuation before starting cleanup so as not to have to make multiple passes through the same records?
As for the Spanish data, there are quite a few Spanish records that were imported by machine in the early days of automated imports and were never cleaned up, and they're often in bad shape in every field. I fix them when I see them but I haven't had time to go after them systematically. --Vasha (cazadora de tildes) 19:02, 14 November 2018 (EST)
Not just Spanish - a few more languages seem to have been imported the same way. Spanish is just the biggest offender. Plus we also have the translators to sort out so we can do 3 in 1 while editing for case, punctuation, subtitles and so on anyway. :)
So Title Regularization invites everyone to contribute so we can start clearing languages. Annie 19:10, 14 November 2018 (EST)

"0" Page Counts - Software Changes; Ebooks

While reading the code earlier today I finally recalled why we had special display logic for "0" page counts. Back in 2006-2009, when ebooks and audio books were not as common as they are today, we tried to come up with a standard for entering them. Both "0" and "unpaginated" were proposed as the preferred way of entering their page counts and the software was updated accordingly. That semi-standard was abandoned years ago and is no longer mentioned in Help.

Based on my findings, I have updated the software not to do any kind of special processing for "0" and "unpaginated" page counts. As of 15 minutes ago, the software simply displays whatever is in the "Pages" field, assuming that it's not empty. I have also removed "0" from the page count fields of all ebooks. Fewer than 2% were affected.

This leaves us with 119 webzines and 9 "other" publications which still use "0" as their page count. I left them alone for now in case anybody wants to look into them. Ahasuerus 17:52, 14 November 2018 (EST)

I will check the "other" ones and update as necessarily. I think that getting the webzines cleaned should not be a problem - they are not different either...
Any chance of adding the nice yellow warning when someone tries to add pages on non-text material? Annie 17:58, 14 November 2018 (EST)
Potential problem: theoretically ebooks don't have pages; however, PDFs, which do have pages, are lumped in with other ebooks --Vasha (cazadora de tildes) 18:19, 14 November 2018 (EST)
We can exclude ebooks for now - I am more concerned about audiobooks and the like at the moment. However - even for PDFs, our rules say not to record page. So... technically those should be empty. If we want to separate the PDFs, we need a separate discussion. But that opens the Pandora box of the old Fictionwise titles (remember those?) that you could download in more than one format, one of them being PDF - and recording all formats as separate books did not make sense. Thinking about that, there are a few publishers like that nowadays as well... Annie 18:26, 14 November 2018 (EST)
Although I unfortunately can't recall exactly what it was, I know I saw one book which was offered in PDF format with illustrations or ePub/mobi without illustrations. Really, PDFs aren't quite the same thing as other ebooks (more similar to a printed book in some ways). But I don't want to start a discussion about that on top of the other 20 ongoing discussions. --Vasha (cazadora de tildes) 18:43, 14 November 2018 (EST)
For some of them. But for a lot of publishers, they are basically the same - just a new format... When there are illustrations in one and not in the other, they should be separate records anyway. Although the current e-book formats support images so... the differences will be less and less. And converting between the formats is trivial. I do not dispute that there are e-books that have pages (from scanned copies of paper books to proper PDFs), we need to decide what we want to do about them before we start adding page numbers (as the current rules do not make a difference). Annie 18:59, 14 November 2018 (EST)
Keep in mind that a yellow warning is just that -- a warning that tells the approving moderator to do more digging. For example, Fixer submissions without a publisher generate warnings, but in many cases they are OK "as is". Ahasuerus 10:00, 15 November 2018 (EST)

SFBC question

I picked up an SFBC copy of Rift in the Sky. It has an SFBC number, 1275245, on the back part of the jacket. ISFDB has this record for DAW Books / SFBC which says "Catalog ID: 08-6848" and "Catalog #/price from the SFBC flyer."

My question is - do SFBC fliers, at least in 2009, have the number that's printed on the jacket? I'm wondering if I should edit the existing record, change the catalog #, and update the notes that that the catalog # in the SFBC flier is 08-6848 and that the publication states 1275245. Or should I create a new DAW Books / SFBC publication record for Catalog # 1275245. --Marc Kupper 02:54, 15 November 2018 (EST)

We have some data here. Just adding some notes - I did some digging when we started the "move the ID project for SFBC". My understanding is that 08-6848 should go back down in the notes (even if it is not your book) as it is catalog number and not an ID number (which is what we put in the catalog field). Cannot help much more I am afraid but I am sure someone will be along with more data... Annie 03:03, 15 November 2018 (EST)
I believe the printed 1275245 corresponds to the SFBC catalog number 12-75245, which I then think means it's a different edition from that of the existing record. --MartyD 07:01, 15 November 2018 (EST)
I do not think that the conversion is that clear cut - ID 1353404 has catalog ID 13-534046 for example and not the expected 13-53404 - the catalog always adds one more number at the end... But I would agree that this looks like a different book though... Annie 14:59, 15 November 2018 (EST)
Thank you. I'll go with a new record as the numbers are very different. --Marc Kupper 02:16, 16 November 2018 (EST)

The Witch of Blackbird Pond

Is this book really eligible for being here? As far as I can tell, it's not actually fantasy at all. Rather, it's historical fiction that has multiple people being accused of being a witch in early New England. We have quite a few publications of it listed. Thoughts? ···日本穣 · 投稿 · Talk to Nihonjoe 14:47, 15 November 2018 (EST)

All 3 verifiers are active so why don't we check if one (or more) of them read the book and can tell us if there is anything speculative? Annie 14:56, 15 November 2018 (EST)
Invited. I read it years ago, and I don't remember any speculative fiction content (as defined here) at all. It's just historical fiction. No fantasy, science fiction, or horror at all. ···日本穣 · 投稿 · Talk to Nihonjoe 15:06, 15 November 2018 (EST)
Ah, did not realize you read it. Let's see if someone else has an opinion (as it is a children book, I wonder if we are not looking at fairy tales kinda situation?). If it is indeed not speculative, I agree that it needs zapping. Annie 15:20, 15 November 2018 (EST)
You can read the summary over here, too. ···日本穣 · 投稿 · Talk to Nihonjoe 16:09, 15 November 2018 (EST)
Yeah, I did not see anything there but then half the magical realism sounds non-speculative to me as well (even after I read it) :) Annie 16:24, 15 November 2018 (EST)
I verified it because I had it, and because it was extensively listed on this site. I've been meaning to read it since I was knee-high to a grasshopper, but I still haven't gotten around to it. I'm assuming that it was added back in the early days of this site, and then people just continued to build on this submission. It was a popular book in its day, but to get the real deal on the content of this book you'll probably have to ask some other geriatric case besides me, who has actually read the book. If it has to go the way of the dodo, then so be it. Too bad you can't ask the general contributors of this site. Maybe on the "help" page. MLB 17:02, 15 November 2018 (EST)
Yeah, I have read it (a long time ago) and don't remember anything speculative. --Vasha (cazadora de tildes) 18:32, 15 November 2018 (EST)
Vasha's right, the "witch" angle is the xenophobia and superstition of the New Englanders and their persecution of the title character. Ofearna 23:14, 16 November 2018 (EST)

(unindent) So anyone opposing the deletion of the title (and all the publications containing it)? Annie 23:40, 16 November 2018 (EST)

I have no objection. It might be nice to copy-and-paste the verified pubs' data to their respective verifiers' Talk pages for reference purposes. Ahasuerus 10:22, 17 November 2018 (EST)
Delete away. That book was in a collection I bought, not a keeper or a read-me. Only entered because it was already listed. --~ Bill, Bluesman 13:50, 18 November 2018 (EST)
Deletion has been completed. Those who had verified any of them have the publication information on their talk pages. ···日本穣 · 投稿 · Talk to Nihonjoe 13:58, 19 November 2018 (EST)

Title checkboxes now appear on the same line

As per this discussion, title checkboxes now appear on the same line. The change affects all New Publication edit forms as well as Edit Title. Let's see if the new layout is an improvement.

P.S. You may need to do a full page reload (Control-F5 in most browsers) for everything to display correctly. Ahasuerus 18:56, 15 November 2018 (EST)

They should be a little farther apart: the labels need to be more visually separated from one another. --Vasha (cazadora de tildes) 19:24, 15 November 2018 (EST)
Good point; I have made the changes. Could you please do a full page reload to see if the spacing looks better? Ahasuerus 20:32, 15 November 2018 (EST)
Yes, that's an improvement. --Vasha (cazadora de tildes) 20:37, 15 November 2018 (EST)
Can we do something about the focus on these fields? At the moment it jumps from Content to Synopsis when you tab through it, skipping the checkboxes (both on addPub and editPub). When I am not working on a touchscreen, not needing to use the mouse to navigate the page is pretty useful. These are also the only ones that are skipped :) Annie 20:41, 15 November 2018 (EST)
Sure, let me take a look. Ahasuerus 20:58, 15 November 2018 (EST)
Done. Ahasuerus 21:11, 15 November 2018 (EST)
You are getting faster and faster in fixing these. Thanks! Annie 21:20, 15 November 2018 (EST)

Google search proposal

(copied from above) Re: lower case versions of non-Latin values, I think it will only get us so far whether we enter them in the existing Transliterated Values fields or in the requested new field. Adding "павел вежинов" to "Павел Вежинов" won't help users who type "ПАВЕЛ ВЕЖИНОВ". Without full Unicode support, it will remain a band-aid. Ahasuerus 17:05, 13 November 2018 (EST)

(moved from above) : No, it won't help the guys that write in caps only but combined with a note on the search result page that mentions that if you are using non-standard Latin characters, you should search in small letters, it will be a better band-aid than anything else we can come up with for the short term... I've never called it a solution - just a short term way to make the DB somewhat usable. Annie 17:43, 13 November 2018 (EST)
Well, if the proposed addition of all-lower case versions of titles/names/etc requires an Advanced Search note to be fully functional, wouldn't it be easier to display an Advanced Search note about the need to use the exact case for non-Latin-1 characters? Ahasuerus 19:25, 14 November 2018 (EST)
Yes but that will require you to know the capitalization rules of the language. Which will be ok for speakers of the language; not as good for a researcher that can read the script but has a shaky idea of the language... And then you have Легуин/ Ле Гуин. When we have all the titles, finding either will work but if you had never seen her name written the other way, that "Guin" will trip you. I am not saying that is a perfect solution - away from that. Just trying to find a workaround... If everyone thinks that this will be an overkill, then I am fine with just adding a note to ask "according to language rules" with a link to the new pages we are building. Either will be better than now :)Annie 19:34, 14 November 2018 (EST)
I had been thinking on that. While this will make our search a bit more manageable, it is really a bandaid. And considering the Russian titles, it will take a long time to update all of them. And a user that is not used to the DB won't really do a second search this way... So... why not use google to help us (someone already mentioned it above - I am just slowly warming up to it). Unlike us, it speaks languages and actually can do some level of autocorrect (which is helpful if you are not strong in a language). So... why not modify the search result page and just give the ability to search in google (with the site name added already and so on. So the built-in search is still there for direct matches but we have a viable way for someone to find something if they do not spell exactly as expected. Annie 22:02, 15 November 2018 (EST)
Yes, it was originally proposed by JLaTondre. I can think of a few ways to leverage Google Search:
  1. Add "Google Search" as a new section within Advanced Search [original proposal]
  2. Add a "Google Search" checkbox to the standard search box, which will alter the behavior of the search logic, redirecting it to Google [my original response to the proposal]
  3. If a search (regular or Advanced) fails, display the standard "No matching records found" message, then display a Google Search button with an explanatory note. If clicked, the button will execute a Google Search for the entered value and the appropriate search type.
  4. In addition to option 3 immediately above, even if a search succeeds, display the Google Search button in addition to displaying the standard results table.
My current thinking is that options 3 and arguably 4 may be our best bet. They wouldn't affect the current workflow and would provide additional functionality without interrupting anything.
The only partial failure scenario (that I can think of) would be the regular ISFDB search engine finding only one matching record and automatically redirecting the user to that record's page. That's what we typically want to happen except when we have other "imprecise" matches which our search logic doesn't find. Still, it appears to be a good compromise. Ahasuerus 23:18, 15 November 2018 (EST)
This is an excellent thought. I like your proposal 3. --Vasha (cazadora de tildes) 01:01, 16 November 2018 (EST)
I'd like to see the link as well when there are results - the more titles and authors we get, the more often we will be getting false positives (aka something matching but not you are not looking for...). Add also a checkbox in Advanced Search that allows the search to be done via Google instead of our search (so you do not need to fail a search first) and we should be all set. Annie 01:08, 16 November 2018 (EST)
(After sleeping on it) Modifying Advanced Search to work with Google may be tricky. We support a lot of different permutations ("Reviewed Author is not exactly Павел Вежинов") which may not directly translate to Google queries. We'll have to review Google's documentation to see which parts can be approximated. It may be best to start with our regular Search, which should be much easier to implement. Ahasuerus 09:06, 16 November 2018 (EST)
I think that my statement went away from me :) I was thinking more in the line of "where to put it so I do not need to fail a search first", the Advanced Search sounded as a nice place and I ran with it. I would agree that putting the whole advanced search out is not as easy. Annie 13:46, 16 November 2018 (EST)
Google is a page search engine, not a database field search engine. They are inherently different workflows. I would not do #3 & #4 with advanced search results. There is not a way to duplicate the field logic and the results could be confusing to users. I'm not even sure I would do it with regular search. I was envisioning adding a new section to the Advanced Search page, labeling it Google Search, providing a single pull down to pick the page type (All, Title, Author, etc.) and a single search box for people to enter terms. Could add some explanations regarding quotes for phrases and negatives for not. Why make it complicated? Most people are familiar with search engines already. Yes, it's more focused at the experienced ISFDB user who understands the limitations of the ISFDB search and why you'd want to use it. But I'm not sure #3 & #4 on the basic search help users who aren't. -- JLaTondre (talk) 10:12, 17 November 2018 (EST)
I think the main reason to add a "Google Search" button when the regular search logic finds no matches is to give less experienced users -- who may not realize that our software doesn't support approximate searches, what Advanced Search options are available, etc -- a simple way to recover. Currently, if they enter "павел вежинов" instead of "Павел Вежинов", the software tells them that we don't know anything about "павел вежинов" and that's it. The proposed "Google Search" button would give them the ability to retry the search near instantaneously. Of course, we'd need to add an explanatory note.
That said, I can see the value in creating a separate "Google Search" section within Advanced Search. I expect that only more experienced users will know about it, but hey, experienced users are people too!
It should be fairly easy to implement and tweak as needed, so I have created FR 1226. I am out of sorts at the moment, so it may be some time before I get to it. Ahasuerus 20:43, 17 November 2018 (EST)

New Template: Narrator

A new template, "Narrator", has been created. Help has been updated. Ahasuerus 10:44, 16 November 2018 (EST)

Haldeman's 'All My Sins Remembered' series

I propose changing the name of Joe Haldeman's series that we currently have under the name of 'All My Sins Remembered' to 'Confederación'. There are other 'Confederación' stories that do not appear in the 'All My Sins...' collection, such as the first four stories in Vietnam and Other Alien Worlds. They're usually/generally referred to as Confederación stories, also by Haldeman himself. Feedback appreciated! PeteYoung 02:40, 18 November 2018 (EST)

Yes, I'm all for it. It's plain better than to name it after one of its titles. Stonecreek 09:52, 20 November 2018 (EST)

Midsummer Century by James Blish and Planet of No Return by Poul Anderson

With just around 100 pages of text as a stand-alone publication and 95 pp. within the same-named collection this has to be correctly defined as a NOVELLA. If there's no objection, I'll merge it with the existing SHORTFICTION. Stonecreek 09:51, 20 November 2018 (EST)

The title record you linked to says:
Expansion of the version published in Magazine of Fantasy and Science Fiction in April 1972.
Have you done a word count to see if it's under 40,000 words? There are three hardcover editions.1 2 3. The word count, not the page count, is how the stories get classified.
The main support for novella is that it's also part of a collection, Midsummer Century, meaning at present we have a collection that contains a novel plus two other novelettes. --Marc Kupper 23:14, 20 November 2018 (EST)
I've done a word count for the German translation: it comes round 34,000 words. It would be good if it's remembered by whom the note was added, if it's based on an actual word count, or was put there because the publisher called the book publication a novel (anyway, even an expansion doesn't have to mean that it was expanded to more than 40,000 words). And the very most examples of publications in book form have shown that there have to be at least 120 pages of text to qualify it as a novel (sometimes even 140 pages are still a novella). Stonecreek 23:47, 20 November 2018 (EST)

The same transformation from NOVEL to SHORTFICTION (novella) seems to hold for the title by Poul Anderson. Are there other (higher) word counts? Stonecreek 15:05, 22 November 2018 (EST)

And also to Anderson's The War of Two Worlds, which is even shorter than Planet of No Return, here. I habe changed both to shortfiction (novella). Stonecreek 10:41, 30 November 2018 (EST)

Canonical name change

The writer formerly known as Joseph Allen Hill is now going by Violet Allen and has had 2 stories published and an award nomination with the latter name. I am going to be changing her canonical name tomorrow. --Vasha (cazadora de tildes) 18:58, 24 November 2018 (EST)

I don't think we reached consensus to do this. Shouldn't the canonical name be Hill with 11 titles published instead of Allen with only 3? --Ron ~ RtraceTalk 09:03, 25 November 2018 (EST)
That's right. No consensus was reached, so the data entry rules were not changed. Template:AuthorFields:CanonicalName still says:
  • the canonical name is the most recognized name for that author within the genre
The only thing that changed based on that discussion was how the software treats alternative names. They used to be called "pseudonyms", now they are called "alternative names". Ahasuerus 10:18, 25 November 2018 (EST)
In the meanwhile, we are still behaving abominably toward transgender authors... It's unacceptable. We need to make the policy change. --Vasha (cazadora de tildes) 13:23, 25 November 2018 (EST)
Perhaps at some point we'll be able to reach a new consensus re: this issue, at which point the policy will be changed. Until it happens, moderators are expected to enforce the current policy. Ahasuerus 14:34, 25 November 2018 (EST)
The fact that moderators (as a community) can't summon up basic courtesy toward authors doesn't say very good things about the culture here, at all. This is an instance where indifference and inaction are affronts. --Vasha (cazadora de tildes) 15:18, 25 November 2018 (EST)
Except that this has nothing to do with courtesy or someone's gender, religion, changed marital status or whatever. We are a bibliographical database - not a biographical one. Our main source are the books - anything else is just supporting data to help us make the DB better. Which is why our definition of a canonical name is not "the name the author prefers or uses now" but "the most recognized" and by extension, "the one that is on most books". I respect the choice of someone to start using a new name for whatever reason but if most of their books still carry the old name, that old name is still the bibliographical name under which people recognize them. Add a note on the author page that as of this date they are using a new name if you want; keep an eye on their output and add anything new until the balance start shifting - but until the majority of books/stories one can read carry the old name, most people will look under that name.
Now... when we opened the DB for webzines and other web sources, that may change the equation a bit - because now the name on the record may change - and we may need to have a discussion around that. But this is not the case here. So let's not throw around accusation of lack of respect and what's not - the field does not record what you want it to - and if you want that to change, start a discussion. A bibliographical one if possible. Annie 17:21, 25 November 2018 (EST)
Blaming lack of respect on "simply following bilbliographic principles" is not a way to get out of responsibility. In fact, it's a classic ploy by people who have the power to chose public naming practices; we must use our power better. Be an ally for transgender people and create a new rule for canonical names that accepts and validates their identity. We would not be overriding any bibliographic data that way. People who look up the old name would simply be redirected to the new one. --Vasha (cazadora de tildes) 17:29, 25 November 2018 (EST)
So in your view a name change is important only when it happens because someone is transgender but not when someone changes their religion or marital status or just feels like it? Why would one require validating while the rest do not? How we record one's name does not depend on their gender, nationality, race, eye color, a change in any of them or anything else like that. We cannot have one rule for someone changing a name because of getting their gender aligned to their identity and a different one for a religion change (for example). If we decide to change the rules, it should not be because of a specific type of a change. And that change needs to go through changing what "canonical name" means in the DB - because it sounds like that is what you have an issue with (and you are conflating that with respecting people and so on). Are we still talking about books and their records here or did that conversation drifted somewhere again?
Yes, transgender people do need all the support they can get. So do a lot of other groups. But making special rules for that is not the way to go - not if you are really looking for normalization and respect. Start a new discussion about changing the meaning of "canonical name" to "preferred/currently used", come up with a plan on how we will follow changes (because otherwise we will end up with a lot of "you changed theirs, why not mine" kind of situations and we can change the rules. Or do we only care when we hear about the change? Annie 17:51, 25 November 2018 (EST)
Reopening a Rules and Standards issue on the Community Portal would only splinter the discussion, so I will limit my comments to the following.
Over the years, we have seen a number of requests to change our bibliographic practices based on their impact on publishers and authors. For example, at one point a user stopped by and argued that some of our practices were harming small presses by making major publishers unduly prominent. At another point an author was unhappy about the inclusion of her works and told us that she never asked us to list them.
To the best of my recollection, none of these arguments have been accepted. We are a bibliographic project. Our primary goal is to create comprehensive and accurate bibliographies. We are not in the business of allying with or validating anyone. We try not to let our personal esthetic, political, national, ideological, etc preferences determine the scope or the policy. If we did, the project would be harmed because we all have different preferences. Ahasuerus 18:34, 25 November 2018 (EST)

"Black Helicopters"

Opinions wanted: should the 2018 version of Caitlín R. Kiernan's Black Helicopters have a separate record from the 2013 version? It sounds to me like it should, based on it being described as "expanded and completed" (as a weaker indication, Tor.com doesn't publish reprints so they must have thought this work was new in some sense). However, I've only seen the new version and would like to hear from someone who's seen both and can compare. --Vasha (cazadora de tildes) 15:15, 28 November 2018 (EST)

Sounds similar to Nina Allan's "The Race" case: here - the second edition added a new section which not only changes how the novel finishes (and shifts the understanding of some earlier sections) but also increases the size significantly. I would think we should have a variant for such significant changes (or even separate titles) but none of the two concepts match exactly (although if an abridgement is a variant, why not expansion?). Anyway... no real idea about what we should do here - just thinking aloud and throwing another similar case in the pot. :) Annie 15:26, 28 November 2018 (EST)
Typically, "rewrites" and "major changes" get their own titles while "revisions" and "minor changes" are documented in Notes. Unfortunately, determining the scope of the changes can be challenging. In this case my first reaction was "The Subterranean Press edition was only 89 pages while the Tor.com edition is 196 pages, so surely it merits a separate title record." However, Tor.com has been known to make novellas (<40K words) look like novels, so their page count doesn't necessarily tell us much. Ahasuerus 16:46, 28 November 2018 (EST)
As moderator, I 'voted' for keeping the title for both incarnations: the question for me was if there's a whole different story told, or if it's another title type (novel). It seemed both were not the case. So, the difference we know of should be covered in the title's note. Stonecreek 04:18, 29 November 2018 (EST)

Tasha Suri

Currently Natasha Suri is the canonical name with Tasha Suri as an alternate, but I think it should be the other way around. "Tasha" is on the cover of a novel which makes it more prominent than the other which is just used for one short story; plus all her web presence is using the name on the novel. --Vasha (cazadora de tildes) 13:57, 29 November 2018 (EST)

Okay when there's a second novel (or of another title type) with her name on the cover. Stonecreek 14:03, 29 November 2018 (EST)
Sorry, that makes no sense. You can't argue that the "best-known" name should be canonical and then not use "Tasha" which is what this author is called in 98 out of 100 references on the web, plus the novel which is a much better-known publication than the story. --Vasha (cazadora de tildes) 14:09, 29 November 2018 (EST)
When dealing with authors who have used multiple names, I usually give more "weight" to novels than to stories. OTOH, it can get tricky if a story is much better known than a novel. For example, Harry Stephen Keeler is probably best remembered for his story "John Jones' Dollar" even though a number of his once popular novels also contained speculative elements. To make things even more complicated, Keeler has experienced something of a revival over the last 20 years. With many of his novels now in print, it's possible that they have once again become as well known as "John Jones' Dollar". Luckily, he only used one name, so it's not an issue for us.
In this case I would use the "novel name" and keep an eye on the author. Ahasuerus 15:01, 29 November 2018 (EST)
OK, I will swap the names, then. --Vasha (cazadora de tildes) 10:28, 30 November 2018 (EST)

Searching books in a specific language

Does anyone have a trick on how to find all the books in a specific language (or all books filtered based on an author or any other element)? Not the titles but the publications - especially in cases where the filter is shared between languages or not always there for that language? I know that I can get to that through searching all titles in that language and grabbing all book under each title (and I know how to do that through the DB) but we do not have a way via Advanced Search, right?

If that is indeed so, how about adding that as an option (where a pub is in a language when its reference title is in that language OR when there is a title inside in that language - whatever makes more sense (dual language books are the ones that will be different based on what we decide; for the rest the results will be the same. Annie 18:15, 29 November 2018 (EST)

Re: "all books filtered based on an author or any other element", the Advanced Publication Search lets you specify the pub author's name, date/place of birth etc. For example, this search gives you a list of books by Павел Вежинов. Ahasuerus 09:53, 30 November 2018 (EST)
Yes but if the name is the same in more than one language, you get too many results - I am looking for the language being an available filter. With some languages there are filters that may help (if I makes sure that all Bulgarian books have prices even when they are just "Leva" or something, I can use that as a filter. But not all languages have single currencies or anything else that will make them unique. Annie 10:26, 30 November 2018 (EST)
"Books [i.e. publications] in a specific language" would be tricky because the search logic would have to find the "reference title" for each publication and then look up its language. Reference titles are not straightforward: magazines and fanzines use "EDITOR" while other publication types have matching title types. A couple of existing cleanup reports check pubs against their reference titles, but the queries are complex and they take a long time to run. I am not sure it would be feasible to add this functionality to the Advanced Publication Search. Ahasuerus 09:53, 30 November 2018 (EST)
How about "any title in the language" inside of the publication? Or any non-art title? I know that the DB is not set for that but... that's a pretty common question. Annie 10:26, 30 November 2018 (EST)
I have created FR 1229 to document the desired functionality, but I expect that it will require a fair amount of tweaking and research. Ahasuerus 13:04, 30 November 2018 (EST)
Thanks! I will look some more to see what else I can figure out as a possible way to filter in the meantime. Annie 14:34, 30 November 2018 (EST)
Maybe this could be a nightly report (or weekly, if nightly would be too much) that's created, in order to preserve server resources. ···日本穣 · 投稿 · Talk to Nihonjoe 14:43, 30 November 2018 (EST)
A report that lists all the books in all languages won't be very useful though and will frankly be an overkill - I am not looking for numbers but for data (which can be filtered)... Annie 14:48, 30 November 2018 (EST)
I meant reports for each language (other than English). If the big ones were spread out across the days of the week so each one was only run once a week, the small ones could be fit in wherever. This way, the information is available, and it doesn't use inordinate amounts of resources whenever someone tries to find them. They could be listed on a separate page like the cleanup reports. ···日本穣 · 投稿 · Talk to Nihonjoe 17:34, 30 November 2018 (EST)
Even for one language - that list won't be much better than what I can get going via the titles search for example with a few separate searches (or directly from the DB) - if you cannot filter it, it is just a list that does not help much but takes a long time to generate (and I really do not want to add another heavy report/computation at 1 am - we are doing much better now but the server is still very sluggish while the jobs run). I know where you are going with you but... it won't really do what I would expect it to. I know the limitation of our DB, I know it won't be trivial - just had to ask in case I was missing an obvious way. Annie 18:43, 30 November 2018 (EST)

Lemuel Gulliver and his famous Travels

Is there a principle by which we sometimes parse a title page so that "by Lemuel Gulliver", for instance, is part of the title of a work rather than its author credit?

For the first edition of Gulliver's Travels, and some others, we have T1719519

Title: Travels Into Several Remote Nations of the World in Four Parts by Lemuel Gulliver
Author: Jonathan Swift

Glasgow University Library "Book of the Month" January 2006 [2], which we link from the title record, displays the original title page of volume one, which shows (quote including horizontal lines):

Travels into several Remote Nations of the World.
In Four Parts.
By Lemuel Gulliver, First a Surgeon, and then a Captain of several Ships.
Vol. I.

At the moment we have only one author by the name "Lemuel Gulliver", credited with only two works: by Lemuel Gulliver. One is the spurious volume three, a 1727 sequel by unknown. The other is an 1812 variant title of Swift's work, with one 1812 publication only. Its internal title page (viewed at HathiTrust) displays "In Four Parts" below the credit to Lemuel Gulliver, First a Surgeon, etc.

P.S. There "into" should be "Into", or vice versa for some the first edition variant titles.

--Pwendt|talk 18:37, 29 November 2018 (EST)

Well, it should depend on naming Swift as the author also on the title page (which does the Glasgow University Library, for example). Stonecreek 00:10, 30 November 2018 (EST)
Am I misreading the title page cited? Neither the link to the Glasgow University image of the title page nor any of our title page images of 1719519 list Swift. Bleiler's Science Fiction: The Early Years describes the 1726 edition as "published anonymously". Bleiler78 lists it as published as by Lemuel Gulliver. Clearly that title record should either be uncredited with "by Lemuel Gulliver" in the title or the name should be removed from the title and these should be under the Lemuel Gulliver alternate name. If I were entering these from scratch I would take the latter approach. --Ron ~ RtraceTalk 21:01, 30 November 2018 (EST)
I'm with Ron here: consider what you would do if you had no foreknowledge. Then looking at the title page Gulliver is the author, and "by Lemuel Gulliver" not part of the title.
Additionally, Gulliver being an alernate name to unknown must be removed and changed into alternate of Swift. MagicUnk 03:20, 1 December 2018 (EST)
The two parent names for Lemuel Gulliver is correct. 1048233 is not by Swift and the actual author is not know. This situation sometimes occurs with house pseudonyms (e.g. Maxwell Grant). --Ron ~ RtraceTalk 08:40, 1 December 2018 (EST)
I'm going to go ahead and change the early editions that only mention "Lemuel Gulliver" to be by that alternate name. If anyone disagrees, we can move them to something else. I would like to ask for opinions on 2088244 I'm inclined to change that one as well. It appears to be one of a four volume set of Swift's works. However, Swift appears on the title page of the first volume as "J. S, D.D, D.S.P.D.". For the Gulliver volume, again "Lemuel Gulliver" is the only author listed. I'm inclined to change this one as well. Again, if folks object, we can change it to something else. --Ron ~ RtraceTalk 20:15, 13 December 2018 (EST)

Linking to the Library of Congress -- Help

As Annie pointed out the other day, Help:How to create a link to a US Library of Congress (Loc) record is out of date. We now use External IDs and a Note template to link to Library of Congress records by LCCN. Is there anything on that page that we can salvage? If not, I will zap it next week. Ahasuerus 17:14, 1 December 2018 (EST)

Wouldn't have created it these days, but since we already have it, I updated it to match current practice. There are a couple of cases that it doesn't hurt to explain for new users. I believe I captured current practice correctly, but people should review. I was going to include more specifics on the ebook example (like the actual LoC catalog field name), but the LoC catalog is down now. I will go back and do that at some point. -- JLaTondre (talk) 09:54, 2 December 2018 (EST)

Publication tags in advanced search

See this discussion for a fuller explanation of the matter. The short version is that advanced search allows you to search for "Tag" in publications and "Title Tag" in titles; however, as Ahasuerus explains, publication tags are not publicly visible anymore after software revisions. Proposal: remove "Tag" from the publication advanced search and rename "Title Tag" to "Tag" in the tile advanced search (which would match the sidebar search, where "Tags" searches titles). Question: does anyone here actually search for publication tags, or have other objections to the proposal? --Vasha (cazadora de tildes) 20:02, 2 December 2018 (EST)

FR 1231 has been created. Ahasuerus 16:13, 9 December 2018 (EST)
Done. Ahasuerus 18:50, 9 December 2018 (EST)
OK, great. --Vasha (cazadora de tildes) 20:31, 9 December 2018 (EST)

External IDs Data Entry

A frequent data entry error that I find myself making is when adding an External ID (usually OCLC/Worldcat or LCCN), I forget to change the type which effectively enters the ID as an ASIN. I correct these when I notice them and have hopefully caught them all. I was thinking that it may improve data quality to have a blank ID type as the default (as we do with the length pull down). Additionally, a client side edit could ensure that a value was selected before sending the edit to the server (like we ensure an author is entered). The only downside I can think of is that if someone enters a large number of ASINs, it's an extra step. Clearly, this wouldn't be urgent or a high priority. Do others feel such changes would be helpful? --Ron ~ RtraceTalk 18:17, 5 December 2018 (EST)

I’d support making the default an empty string thus forcing a selection. I tend to patrol the ASIN list for anything that does not start with B monthly. There are legitimate cases but most of those need moving elsewhere. Annie 18:23, 5 December 2018 (EST)
There was previously a proposal to add the option to add a Preferences setting for which external ID is at the top by default. I like that better than the blank idea but the blank is better than what we have now. --Vasha (cazadora de tildes) 18:29, 5 December 2018 (EST)
Another default will just move the issue - at least with a default in ASIN, we easily find the ones that are forgotten. You move that default to one of the number only IDs (OCLC, GR and so on), it gets exponentially harder. So the more we can do to minimize mistakes, the better... I know that there is the case with people using only one ID type but still... Annie 13:42, 6 December 2018 (EST)
From a purely technical perspective it would be easy to do what Ron proposes. Ahasuerus 15:03, 6 December 2018 (EST)
Why not make a combination of both proposals? Allow default setting per user, including blank. MagicUnk 15:31, 6 December 2018 (EST)
Different levels of effort I would think -- the adding of the blank is easy enough (add a new element, make sure it is not accepted during submissions on add/edit/clone pub); adding a new default will mean adding new element on the defaults page, changing the three pub pages to account for it and still have the other changes for the empty value. And then there are the priorities - do we really want that more than some other FRs that had been standing and waiting for years? Annie 13:47, 7 December 2018 (EST)
Right, we have two separate things here. The default blank can be implemented if no one objects (I don't); the option to override it if you're entering lots of IDs of the same type is a low priority idea to keep in mind. --15:40, 7 December 2018 (EST)
We already have an FR (FR 1163) to "Create a new User Preference for the default External ID type", so I have created a new one, FR 1230, for this issue. Ahasuerus 13:24, 9 December 2018 (EST)

External IDs Data Entry - First Change Made

FR 1230 has been implemented. Depending on your browser, you may need to do a full page reload (Control-F5 under most browsers) for the new functionality to take effect.

Once we determine that everything is working as intended, we can discuss whether:

  • we still want to implement FR 1163 (which shouldn't be as labor-intensive as I originally thought), or
  • whether the possible unintended side effects as described by Annie above would outweigh its benefits.

Ahasuerus 17:36, 9 December 2018 (EST)

I was just coming to say that this was quick - thanks for the change. EditPub is working as expected. :) Annie 17:39, 9 December 2018 (EST)
Wanted to say the same thing, but Annie beat me to it. Thanks. --Ron ~ RtraceTalk 17:51, 9 December 2018 (EST)
Sure thing. Actually, the change took a few days to code and test. In part it was due to the fact that I used this FR as a test case to get the kinks out of the development process on the new server. I also had to rewrite the way external IDs are validated on the server side because the original design was suboptimal. (Fixer tells me that it was "beyond suboptimal", but I think he is just being cranky because I haven't been able to spend much time with him lately.) Ahasuerus 17:56, 9 December 2018 (EST)
I just happened to be in the middle of yet another batch of OCLC identifiers that needed moving and the default changed on me. Thus finding out about it so quickly. And Fixer should stop being cranky - he just had a vacation while his house was getting repainted. Maybe he was just lonely...
Any chance we can add a JS based validation on the front end (in addition to the one we have on the backend) - if it goes down to the yellow warning and you have multiple IDs, all but the first are lost when you go back to reedit (at least in Chrome). Which may get annoying. :) Annie 18:24, 9 December 2018 (EST)
The browser is supposed to display a pop-up message when an External ID value is entered for a blank External ID type. Did you get that yellow error message before you had a chance to do a full reload (Control-F5)?
P.S. The main reason why I use Firefox for ISFDB editing is that it does a much better job of preserving entered data when I need to go back a page or two. Ahasuerus 18:58, 9 December 2018 (EST)
Yeah, too many open windows - apparently I never reloaded the one - thought I did. Sorry about that. Tried again - works as expected.
PS: I use FF on my Windows laptop and vastly prefer it to Chrome; the Chromebook has Chrome as a native browser though and it performs a lot better than FF (that essentially runs as an app on the Chromebook). But even FF loses the multiple identifiers (at last the last time I had to back out from a multiple identifier edit). Annie 19:05, 9 December 2018 (EST)

(unindent) I'm in favour of having FR 1163 implemented. I believe it would not sit in the way of anyone that doesn't want a default. And those editors that want a personalized default are assumed to know what they are doing :) MagicUnk 16:42, 11 December 2018 (EST)

A "Redo" Button

Just wondering - has anyone ever requested a "Give me a redo" button on the edit confirmation page - something that would cancel the just-submitted edit and give you an edit screen with everything you just submitted? ../Doug H 08:18, 10 December 2018 (EST)

Yes, indeed -- see FR 21, "Ability to 'Edit' Proposed submission", requested back in 2009. Nothing has been done so far because it would be labor-intensive to implement. Ahasuerus 10:41, 10 December 2018 (EST)
You may already know this, but as a workaround (and using Chrome in my case), I just press the browser back button, do the necessary changes, (re-)submit, and then cancel the previous edit. Do be aware of one catch; multiple author, external ID,... records are not remembered beyond the first, so you'll have to re-add these. Works like a charm otherwise... MagicUnk 14:52, 10 December 2018 (EST)
Another issue with the "back" option, at least in some browsers, is that you may not retain any additional content items you added past the first nine, and if you're editing an existing publication, you may not retain new content items you added to the ones already there. In short, any part of the form that was added with an "Add Author/Title/External ID/etc." button will not be retained. --Vasha (cazadora de tildes) 15:07, 10 December 2018 (EST)
Or multiple transliterations if I remember correctly (basically the plus signs get a bit wonky using the back button. I tend to compare how much repair work is needed compared to how much time it will take to recreate from the wrong record. Annie 15:13, 10 December 2018 (EST)

(unindent) Yup, run into most of those, which is why I asked. So here's a slightly different take - could the Submit button be allowed to open in a new window/tab? ../Doug H 16:38, 10 December 2018 (EST)

That would get messy. It'd be even easier than it is now to submit multiple times (either identical or varying submissions) if you had several tabs open including an open form that you couldn't tell if you'd submitted yet or not. --Vasha (cazadora de tildes) 16:48, 10 December 2018 (EST)

(unindent) Here's a suggestion: How about putting a "cancel this submission" link on the page reviewing the submission. That way, if the editor needs to hit the back button and fix something, or if Doug's suggestion to open the review page in a separate tab is accepted, the editor can easily cancel the erroneous submission before doing the edit, which will make double submissions much less likely. --Vasha (cazadora de tildes) 20:49, 12 December 2018 (EST)

External Identifiers help updates

We really need to update this one - we had added a lot more of these so the list is a bit obsolete. As it is a live help page, I am reluctant to edit on my own - although if there are no objections, I can do some editing tonight. Annie 13:32, 10 December 2018 (EST)

Go for it! :) Ahasuerus 18:26, 10 December 2018 (EST)
Updated. Any updates/recommendations and so on are welcome. I added some notes where finding the ID can be tricky (or confusing) - hopefully that will reduce the number of weird IDs showing all over the place). Annie 20:18, 10 December 2018 (EST)

Interzone: Digest to Pulp

I noticed that the size of recent Interzone issues is 17 cm x 24 cm, which is pulp rather than digest. They should all be changed from 2012 onward. But before I submit these changes I want to make sure I'm not missing anything... MagicUnk 06:31, 11 December 2018 (EST)

'Pulp' certainly would be misleading (because of the connotations of a certain period of time and paper quality), though they are not digests either. The issues I have are tps and as this is nowadays an accomplished format for magazines, I'll begin to switch them to that. Would you like to do the same to your verified ones? Stonecreek 10:42, 11 December 2018 (EST)
Should we really change them to tp? Size of tps are ill-defined and is a bit of a catch-all if you ask me, whereas pulp is exactly the dimensions we're talking about. I understand pulp is associated with the cheap-paper periodicals, but should'nt we rather expand/clarify the definion instead? Or alternatively, add a new format - equivalent to pulp but with a different name? MagicUnk 12:34, 11 December 2018 (EST)
Well, tps are really well-defined and it seems the standard format for modern (post 2000) print periodicals that don't fit into other magazine standards, and are very similar or identical in format to Interzone. See the following examples: Clarkesworld, Apex, or On Spec. Stonecreek 13:19, 11 December 2018 (EST)
Christian, can you elaborate on why you state that tp's are well-defined? When I'm reading the Format field info, it states that its size can be whatever, as long as minimum dimensions are 19 cm tall or 11 cm wide. Not very precise if you ask me... MagicUnk 16:36, 11 December 2018 (EST)
Template:PublicationFields:Format says:
  • Print magazines
    • pulp - the common pulp size: 6.5" × 9.5" (16.5 cm x 24.1 cm). For ISFDB purposes this may also be used as a designation for the quality of the paper. There are some untrimmed pulps that are as large as 8" × 11.75 (20.3 cm x 29.8 cm)"
    • tp - trade paperback magazines, usually perfect-bound, i.e. periodical publications (often POD) which otherwise would qualify as trade paperbacks (see "tp" in the Print books section)
The parts that mention paper quality are a big vague: "this may also be used as a designation for the quality of the paper" and "usually perfect-bound", but the language seems to suggest that "tp" would be the preferred way of entering modern magazines. I can't think of a better term that we could use, but if there are suitable candidates, we could start a new Rules and Standard discussion. It would be easy to add a new value to the list of supported formats. Ahasuerus 14:36, 11 December 2018 (EST)
mm for modern mags, or modern for short? MagicUnk 16:39, 11 December 2018 (EST)
OK, changed. Stonecreek 06:11, 13 December 2018 (EST)

Nonstandard capitalization in a poem title

I'm having a slight disagreement with Christian. The title of this poem is printed "YUAN: the Origin of a Family Name" in the issue of Mithila Review that I catalogued. Christian thinks the capitalization should be standardized to "Yuan: The Origin of a Family Name" in the database. But I disagree because of the part of the ISFDB policy that states "Titles should have case regularized according to language-specific rules unless there is some specific evidence that the author intended certain letters to be in a specific case." I think it is clear that the author intends YUAN to be all caps because it appears that way not just in Mithila Review, but in its other publication in Manifest West: Transitions and Transformations.

On the other hand, Mithila Review prints the word "the" after the colon lowercase, but Manifest West prints it uppercase. I have no problem with standardizing that word to the usual uppercase. So, the result should be "YUAN: The Origin of a Family Name." What do you think? --Vasha (cazadora de tildes) 14:11, 11 December 2018 (EST)

Looking at Piers Anthony, you get "DoOon Mode" and "OX", which make sense in the context of the story, but you also get "SOS the Rope" followed by "Var the Stick" and "Neq the Sword" and the inconsistency looks weird. Is the capitalization consistent through the story/article? ../Doug H 22:27, 11 December 2018 (EST)
Read the poem here: it goes through the name letter by letter which makes Y-U-A-N a sort of acronym! --Vasha (cazadora de tildes) 23:19, 11 December 2018 (EST)
Hi, Vasha! If you'd stated something like that in the notes it would have been obvious why the capitalization was chosen. I'll change the title and add a note. Stonecreek 23:47, 11 December 2018 (EST)
OK, thanks. The thing is, though, a lot of poems use weird capitalization without such an obvious reason for it. You kind of just have to accept that what's in the publication is what is intended. I tend to standardize the capitalization of story titles but not poem titles.
Does anyone want to start a R&S debate over what constitutes "some specific evidence that the author intended certain letters to be in a specific case"? --Vasha (cazadora de tildes) 00:08, 12 December 2018 (EST)
Most moderators should be accustomed with all-small-letters for poems, but for cases like this one (or others that may deviate in other ways) it really seems better to add an explanatory note to the title: the next editor / moderator might think in the same way as me and change the title back again. Stonecreek 04:38, 12 December 2018 (EST)
Notes are always good :-) Ahasuerus 13:18, 12 December 2018 (EST)

New cleanup reports - External IDs

Seven new cleanup reports have been deployed as per FR 1232, which see for details. The data -- a couple hundred publications -- will become available tomorrow morning. Based on preliminary testing results, one of the reports may need the ability to "ignore" records added, but let's wait until everything else has been corrected.

I was going to start working on other recently requested FRs, but it looks like I need to take a break since I am not feeling well. Hopefully a short one. (Fixer says that he has a custom anti-virus program ready for me, so I am sure I'll be fine. If you can't trust Fixer, who can you trust, right?) Ahasuerus 23:21, 11 December 2018 (EST)

Some fun new reports turned out these to be. Some people might need to see an optometrician, if you'd ask me.--Dirk P Broer 11:38, 12 December 2018 (EST)
Well, we have a tad over 532,000 pubs and 220,000 external identifiers on file, so 200 problem pubs is around 0.1%. Even Fixer agrees that it's not too bad for carbon-based lifeforms :-) Ahasuerus 13:34, 12 December 2018 (EST)
0.1% is indeed very acceptable. Some of the titles are in the report by error too, e.g. Der Zeitagent.--Dirk P Broer 17:04, 12 December 2018 (EST)
Der Zeitagent's OCLC ID was displayed as "74965890", but the actual stored value was "74965890</". The angle bracket and the slash were not displayed because browsers interpreted them as HTML markup.
The 4 tagged Japanese pubs may require more digging -- I will ping Nihonjoe. Ahasuerus 17:24, 12 December 2018 (EST)
Fixed! Well, mostly. See my talk page. ···日本穣 · 投稿 · Talk to Nihonjoe 20:20, 12 December 2018 (EST)
Thanks! The NDL-specific logic has been adjusted to allow leading "b"s. Ahasuerus 23:33, 12 December 2018 (EST)
The LCCNs also seems to be able to have a few letters as a lead (a, ac, unk, tmp, ltf and war are the ones I saw today but there aren't too many of them so let's leave the LCCN report as is - we can just ignore them for now when they show up. I will keep an eye for some of them getting too plentiful. Annie 00:12, 13 December 2018 (EST)

ISFDB Statistics page

The ISFDB Statistics page has been updated to display External ID information. The data will become available tomorrow morning. Ahasuerus 20:18, 12 December 2018 (EST)

Google Search - Take One

As per FR 1226, Advanced Search has been enhanced. The new section, cleverly called "Search ISFDB Using Google", lets you select one of the currently supported record types:

  • name (default)
  • title
  • series
  • publication
  • publication series
  • publisher
  • award category

and then choose between "contains approximate word" (the default) and "contains exact word". I have tweaked the Google query syntax to approximate what I think users will expect to get. However, Google's search algorithms are somewhat mysterious, so the results are occasionally a bit odd, especially if you move to pages 2, 3, etc. Still, a search on "ПАВЕЛ ВЕЖИНОВ" (Annie's example from the original discussion) finds "Павел Вежинов" and, if you choose "approximate", also finds "Pavel Vejinov", which is more than we can currently do.

Please let me know what you think of the current implementation. If we have developers familiar with the way Google Search works, I'd appreciate their feedback.

If and when we determine that this is useful, we can update the regular search logic to display a "Google Search" button if a search fails to find anything. Ahasuerus 23:36, 13 December 2018 (EST)

I am not sure if it is just my security settings or a generic problem with Chrome but the forward to Google does not work (Ctrl + F5 did not clear it either). A right click to open in a new tab works - but not a straight click. Will check with FF and another Chrome tomorrow morning. Other from that - nice! Annie 00:25, 14 December 2018 (EST)
Curious. Here is what Chrome says:
We do have this CSP directive in place as part of our security framework. However, I don't think it should apply in this case because the code uses a server-side redirect rather than a direct submission. Firefox apparently agrees and processes the redirect seamlessly. I'll do more digging tomorrow morning -- thanks for the heads-up! Ahasuerus 00:42, 14 December 2018 (EST)
It turns out that this is a known issue. Firefox interprets one of the Web security standards one way while Chrome and Safari interpret it another way. I am currently in the process of trying to come up with a workaround that will work for all browsers. Ahasuerus 12:33, 14 December 2018 (EST)
And now I remember why I hate doing web development. Thanks for looking into this :) Annie 12:42, 14 December 2018 (EST)
The internet (and computers in general) have been growing so fast over the last few decades that half the time I am surprised that things work at all. On occasion I feel like Buster Keaton in The Electric House... Ahasuerus 13:26, 14 December 2018 (EST)
The software has been adjusted to work with Chrome and Safari. Ahasuerus 14:25, 14 December 2018 (EST)
Thanks! Appears to be working (on Chrome on Windows; will check the Chrome on the Chromebook tonight).
PS: Yeah and things change faster and faster these days. It is almost frightening when you are the one building what people need to use... Annie 14:50, 14 December 2018 (EST)

(Unindent) It works on Microsft Edge and the Samsung browser too. --Vasha (cazadora de tildes) 17:54, 14 December 2018 (EST)

Thanks for checking! Ahasuerus 20:10, 14 December 2018 (EST)

Cleanup reports - consolidation

We have 245 nightly cleanup reports. It's a good thing, of course, but the software was not originally designed to have that many reports and things have become unwieldy.

I am currently in the process of consolidating and streamlining the code. The first patch was installed a few minutes ago and will affect the nightly run in 2 hours. I expect more patches to follow in the next day or two. There should be no user-experienced changes, but if you notice anything strange, please report your findings here. Ahasuerus 23:04, 14 December 2018 (EST)

If you accept ideas for consolidation, all those language specific transliteration reports can be merged together. Same with suspected author languages and so on. They were huge when we started the transliterations and the title languages but these days they are either empty or very small... Annie 01:47, 15 December 2018 (EST)
The number of records that we were originally dealing with was one of the reasons why multiple language-specific "transliteration" reports were created. However, there was another reason: most of us are not able to add transliterated values across the language spectrum. I can do it for European languages, but Japanese is beyond me. On the other hand, Nihonjoe can handle Japanese, but not Bulgarian, Serbian, Russian, etc. Thus even though the number of records found by these nightly reports is low these days, segregating them by language still seems useful. If I look at the list and see that only Asian languages are outstanding, I don't need to drill down since I can't help anyway. Ahasuerus 13:44, 15 December 2018 (EST)
Except that the catch-all is not just Asian languages - Croatian ends up there for example. Or Bosnian. Or any number of other languages we do not see often. So I end up always checking it anyway - and seeing that it is an alphabet I do not know, I just skip these. :) But if you think they are useful as they are, no worries. I was just thinking aloud. Annie
Would it help to consolidate all of our "transliterated" reports based on whether the language's primary alphabet/script is:
  • Latin-based
  • Cyrillic-based
  • Other
? It wouldn't be perfect because of multi-alphabet languages like Azerbaijani, Serbian, etc, but it may be an improvement. Ahasuerus 15:25, 15 December 2018 (EST)
The way I work on these reports - yes. Make a decision for the multi-alphabet ones (stick them with the less-common one would be my vote- if you read Cyrillic for example, you can deal with the Latin forms of the same alphabet) and we are all set. Annie 15:34, 15 December 2018 (EST)

Some absent Theodore Sturgeon reviews

I've had a snail-mail enquiry from American fan John Hertz (he's never had email, ever, and never will) who has noticed that we include book reviews that Theodore Sturgeon did for Galaxy 1972-1975, Venture 1957-1958, but not National Review, The New York Times or, to be complete, Hustler (under Paul Krassner, ed. 1979-1983).

Unless I've missed it somewhere, I see nothing under the Rules of Acquisition the specifically prevents us from including reviews by a prominent genre author such as Sturgeon that appeared in non-genre periodicals – can anyone point to examples of periodicals where we do include such reviews? And if not, is there a reason for this exclusion or is it just lack of the necessary bibliographic data? A cursory look at The Kenneth Spencer Research Library shows such reviews are listed there, and maybe John Hertz knows of other resources. John's enquiry about our missing bibliographic detail shows this is obviously important to some people who would expect to find such information at our site. Input please! Thanks. PeteYoung 07:59, 15 December 2018 (EST)

Help:Entering non-genre periodicals#Genre special issues has "even though we do not normally catalog non-fiction from non-genre magazines" which isn't definitive. It's been discussed a couple of times with no real conclusion. You will occasionally see non-fiction included when there is fiction, but non-fiction from a non-genre magazine without accompanying fiction is pretty much not done (though it wouldn't surprise me if some has made its way into the database). -- JLaTondre (talk) 08:55, 15 December 2018 (EST)
I'd vote for an inclusion of reviews that take on genre titles and such done by authors above-the threshold, regardless of where they were published: both cases are useful for completing our core business (genre authors, their works and how they are viewed). Stonecreek 07:41, 16 December 2018 (EST)
The rules of acquisition declare "works about speculative fiction" as "in" (Included #3). So I believe a review of a title eligible for inclusion is likewise eligible for inclusion, regardless of where it was published. But the rules of acquisition also limit inclusion of non-genre non-fiction by authors above the threshhold to that published "as a standalone book" (Included #4). So I believe a Sturgeon review of a non-genre title in a non-genre periodical is explicitly excluded. I don't have a strong feeling about it, but that treatment seems appropriate to me. --MartyD 10:02, 16 December 2018 (EST)
I've gotten the impression that that "works about speculative fiction" inclusion is also pretty much limited to stand-alone works. Not that there's a set-in-stone policy about it, just that several discussions over the past three years have shown the current group of editors to be unenthusiastic about cataloguing nonfiction and unwilling to interpret rules in ways that would allow much of it to be entered. Somebody (I unfortunately don't recall who) said that they thought nonfiction should only be entered in order to show what the complete contents of genre magazines are. That's an extreme position, but no one really disagreed with it in that discussion. For my part, though, I don't think it would do any harm to enter some non-genre periodicals if they have interesting contents. An exception here or there, in order to have the complete genre writings of significant authors included, not just their complete genre fiction. --Vasha (cazadora de tildes) 10:35, 16 December 2018 (EST)

(unindent) One of the problems that we have run into when discussing what types of non-fiction to include is the sheer number of different ways to categorize them. Off the top of my head:

  • Length: books vs. short works. Short works are further subdivided into:
    • Essays vs. reviews vs. interviews
  • Type of publication where the non-fiction work appeared: genre periodicals vs. non-genre periodicals vs. genre books vs. non-genre books
  • Type of non-fiction work: works about written SF vs. works about non-written SF (comics, films, TV, etc) vs. works about non-genre issues vs. works that are "sort of" related to SF (space exploration, history of myths, etc)

This segmentation makes it difficult to ensure that everyone is on the same page when discussing proposals that cover only certain "cells" of this multidimensional matrix. Perhaps a graphical (tabular?) representation may help clarify what our policy currently says and where we may want to go from here. Ahasuerus 16:44, 16 December 2018 (EST)

In memoriam -- magazines

It's been a bad, bad year in genre magazine publishing. Numerous long-lived, respected, and beloved magazines announced their closure: Space & Time after 52 years of operation, saying that the economics of the distribution system have changed so that it is impossible for them to stay in print; Mythic Delirium after 20 years, Shimmer after 14 years, SQ Mag after 8 years... Young adult spec fic lost a pro-paying market with the end of Cicada magazine. Other magazines struggle to stay in production: Cemetery Dance did not produce an issue this year, and Lackington's only delivered two issues instead of its customary four. The Strange Horizons fundraiser was not quite as successful as they'd hoped. Economic woes were everywhere. Although new magazines were launched, hope was greater than reality: the revived Omni, greeted with enthusiasm, lasted one issue. I very much enjoyed the first two issues of Eyedolon magazine, but since then their production of new content has been sparse.

Genre short fiction will still be published--it must be, since people will not stop writing and reading it. But the chances of writers being paid for their work continue to grow worse and worse. Magazine publishing as we know it is changing, and magazines are fewer. I don't know what form short fiction publishing will take in the future. I send respectful thanks to the magazines that have ended their run this year, and hopeful wishes to everyone who intends to keep publishing. --Vasha (cazadora de tildes) 15:43, 15 December 2018 (EST)

Unfortunately, I know very little about the short fiction market these days, so I can't venture any guesses as to what's going on. It would be great if we could mine our data for patterns, but all I can think of at the moment is "Titles by Year of First Publication", which has separate graphs for novels and short fiction, and "Publications by Year", which has a graph for magazines. They are not terribly illuminating, but they are better than nothing.
Since I am still recovering and can't do heavy duty development work, I have added a POEM graph to "Titles by Year of First Publication". The data will become available tomorrow morning. Perhaps we should add a graph showing the breakdown of magazine formats (pulp, digest, webzine, etc) to "Percent of Publications by Format by Year"? The "Space & Time" editor mentioned that:
  • As for going online only, there’s already a glut of high-quality genre publications vying for eyeballs — it’s simply not worth the effort required to assemble issues for so small a readership.
It may be useful to try to quantify this "glut", as she called it. Ahasuerus 21:32, 15 December 2018 (EST)
I realize that my ill-chosen headline makes it sound like I intended to say "The genre magazine is dead!" I did not mean that, I just meant to post an in memoriam and thanks to certain specific magazines that ended their run this last year. That led to reflecting that the general situation is in transition to who-knows-what. --Vasha (cazadora de tildes) 04:12, 16 December 2018 (EST)
In my experience, when a well-read genre fan thinks that the field has changed, there is a very good chance that he or she is right. However, determining the nature of the change may not be easy. Granted, in certain cases, e.g. during the "death of [US] science fiction" period in the late 1950s and early 1960s, it was fairly straightforward. All you had to do in 1962 was plot the annual number of SF magazines and magazine issues since 1953 and the picture was perfectly clear. Hence Alva Rogers' A Requiem for Astounding in 1964, although he also argued that, in addition to a quantitative decline, science fiction had lost its "sense of wonder", a much more difficult proposition to prove or disprove.
However, in most cases things are not that simple. Sometimes the relative popularity of sub-genres changes. For example, the recent flood of urban fantasy and paranormal romance works has done little for cyberpunk fans. Other times the underlying change is technological in nature: readers who are less willing to use e-books may have been negatively affected by the changes over the last 10+ years. Then there are generational and esthetic changes as was the case during the "New Wave" controversy of the late 1960s. And so on and so forth.
It would be great if we could use our data to quantify these changes. For example, in addition to the ideas that I mentioned earlier, perhaps we could update Titles by Author Age to show how the "age at the time of first publication" has changed over the years. Or we could show how the average magazine editor age has changed over time. We could also create a graph showing changes in the relative popularity of various title tags. More ideas are always welcome! Ahasuerus 15:29, 16 December 2018 (EST)

REVIEW, INTERVIEW, COVERART and INTERIORART series

As per FR 1213, "Let all title types appear as series", the software has been modified to fully support REVIEW series. INTERVIEW, COVERART and INTERIORART series are still outstanding. Ahasuerus 19:22, 16 December 2018 (EST)

Support for INTERVIEWs has been added. You can now put them in a series and they will appear correctly -- see William Sullivan's Summary page for an example. Ahasuerus 19:59, 16 December 2018 (EST)
Support for COVERART and INTERIORART series has been added.
In most cases everything looks OK, e.g. see Alfons Figueras's Summary page. However, mixing COVERART and INTERIORART titles in the same series can lead to unexpected results. For example, if you pull up Virgil Finlay's Summary page and scroll down to the "Cover Art Series" section, you will note that the "Virgil Finlay's Poetry Series" series contains 22 INTERIORART titles and only 1 COVERART title. This is due to the fact that the Cover Art section is displayed before the Interior Art section: all INTERIORART titles that belong to a series with at least one COVERART title in it are displayed in the "Cover Art Series" section. This is the way all other title types work, so I don't think we need to change the software, but we'll want to keep it mind when adding series information to art titles. In certain cases creating two separate series may be a better way to organize our art records. Let's wait a few days and then we can discuss whether we need to create a cleanup report for "mixed art" series.
Finally, please note that I have moved the 2 art sections below "short fiction", "poems" and "essays". We are primarily a fiction database, so it makes more sense to display fiction titles before art titles. If this causes a problem, we can revisit the display order. Ahasuerus 21:04, 16 December 2018 (EST)

Interviews BY vs. Interviews WITH

I can't decide whether it makes sense to have them displayed in series on the interviewer page but not the interviewee page. It is definitely nice to have the interviewer displayed this way. Now it makes sense that we've been adding the Lightspeed and Nightmare author spotlights to series, because it looks good to have the recurrent work the interviewer did for this department displayed together on their page. In the case of author spotlights, some interviewees have been interviewed multiple times for Nightmare and Lightspeed, and it might look good to have those grouped together too; but in general, it makes rather less sense to have the interviewee displayed in series because often they've just contributed once to that series. --Vasha (cazadora de tildes) 20:53, 16 December 2018 (EST)

One thing to keep in mind is that the "Interviews WITH" section is very different from the other sections on the Summary page. It displays titles that the main author is associated with, but is not the author of. For this reason the software that displays "Interviews With" is completely different and not as robust as the rest of the software on that page. For example, it doesn't handle VTs -- see FR 1337, "Display VTs in the Interviews With This Author section of Summary pages". We can modify it, but it's a fairly big can of worms. Ahasuerus 21:12, 16 December 2018 (EST)
OK then, it's a good thing I decided I didn't want the "interviews with" displayed in series if it isn't possible anyhow! --Vasha (cazadora de tildes) 21:32, 16 December 2018 (EST)

The External IDs migration

Just in case anyone is interested, as of 5 minutes ago all external identifiers that were in the Notes fields as links had been either moved to the new fields or templated. Additionally all non-linked ones in predictable (and sometimes not so predictable patterns) had been also dealt with. All wrongly templated ones mainly from March-August 2017 (when we were still figuring out what we were doing) that should have been in the new fields were also checked and moved if needed. So if you are tired of your "Changed Primary Notifications" getting lighted up as a Christmas tree daily, that will stop happening. Until we have another cleanup project that requires that many publications edits that is. :)

If anyone finds a non-moved/templated ID, please move/template it if it makes sense (lccn that cannot be found in LOC for example stays unmoved and untemplated and so on). Or post here or on my wall so I can move it. If you find a pattern yielding more than one, I will be more than happy to work through them.

But for now, besides the 23 Japanese Audible ASINs that we are still researching, the moving of external IDs is completed. Annie 02:12, 19 December 2018 (EST)

Wow, that was a load of work. Great that you did this Herculian task, Annie! Stonecreek 02:15, 19 December 2018 (EST)
Congratulations on slaying the dragon! Don't look now, but there is another weyr right around the corner :-) Ahasuerus 08:01, 19 December 2018 (EST)
Ahasuerus, just the one? :) Christian, that one was a team effort - at different times in the last 18 months pretty much everyone chipped at these. Although a couple of weeks ago I did wonder briefly if I will ever stop finding more and more creative ways found by the editors to record these IDs in the Notes and if just giving up on patterns and opening every single publication won't be faster (nah, it would not have been - but those things just kept showing up). If anyone ever needs a proof on why we need more structured fields, this migration will probably be the example in the dictionary. :)
Onto the next project now. Annie 10:39, 19 December 2018 (EST)
Annie hunts IDs, she finds them where they lurk / Tireless editor, to you we say "Great work!" --Vasha (cazadora de tildes) 11:00, 19 December 2018 (EST)

(unindent) The cleanup report has been simplified to look for any and all occurrences of 'worldcat.org/" in the Note field. The new version of the report lets moderators "ignore" records. I expect that of the 19 records that the report will find when it runs overnight all (or almost all) will be "ignored" tomorrow morning. Ahasuerus 17:42, 19 December 2018 (EST)

Thanks for updating that one. Unless someone manages to smuggle a new one in, all 19 will be ignored as soon as the report manages to regenerate :) Annie 18:05, 19 December 2018 (EST)

New OCLC cleanup reports

Two new cleanup reports have been deployed:

  • Publications with an OCLC Verification, no ISBN and no OCLC External ID
  • Publications with an OCLC Verification, an ISBN and no OCLC External ID (first 1000)

The only difference between them is that the second one has an extra column for the ISBN. Displayed ISBNs are also linked to OCLC.

There is no way to "ignore" records at this point. We may need to revisit this issue once the bulk of the records has been processed: there are some unusual scenarios involving magazines and OCLC errors.

The data will become available tomorrow morning. I expect that the first cleanup report will have 397 records. The second report should find approximately 3,621 records, but the display is capped at 1,000 for performance reasons. We are getting ever closer... Ahasuerus 19:30, 19 December 2018 (EST)

I will make that case that if it does not have an OCLC record to connect to, it should not have been marked as verified... Verified means "there is a record describing THIS book" and I verified against it, not a book or series related to this book or containing this book (this is what templates are for)... Annie 19:40, 19 December 2018 (EST)
If all OCLC-verified publications end up with an OCLC ID, it will effectively make OCLC verifications redundant. At that point we will presumably want to consider whether we want to keep OCLC as an active verification source. Since some editors grow attached to their verifications, we may want to preserve their contributions on the Top Verifiers page, which shouldn't be hard to do. I guess we'll revisit this issue once the new cleanup reports have been processed. Ahasuerus 16:37, 20 December 2018 (EST)

(unindent) How do we look in the other direction - publications with OCLC number but without a verification? Some of those will be as easy as a click; some will need updated notes to note discrepancies, some may actually end up with us updating our records. Annie 10:22, 21 December 2018 (EST)

I guess it depends on what we decide to do with OCLC verifications. My tentative take on them is that OCLC IDs effectively supersede OCLC verifications. The additional information that secondary verifications provide -- the "N/A" capability, the name of the editor and the date of the verification -- doesn't seem to add much as long as we have OCLC IDs. If that's what we end up deciding, then we'll probably "freeze" OCLC verifications, i.e. disallow new ones and possibly stop displaying the existing ones. We won't be deleting them from the database in case we ever change our mind. They will also be displayed on our statistical reports. Ahasuerus 22:23, 21 December 2018 (EST)
That is a good plan. I also think there's likely no need to double-check the OCLC IDs that don't have verifications; although doubtless some of them are wrong, they're no more likely to be wrong than the verified ones. And although it's nice to note discrepancies between the WorldCat record and other sources of data, how high a priority is that? --Vasha (cazadora de tildes) 22:46, 21 December 2018 (EST)
Low priority for you is not the same as low priority for someone else. We are talking about editors' time here - everyone works on what they find relevant to them. So let's not make decisions for other people... And if data quality and proper notes are low priority, especially when we work from secondary sources, maybe we have a different ideas of what is important :) Annie 23:27, 21 December 2018 (EST)
Noted, my apologies. --Vasha (cazadora de tildes) 00:25, 22 December 2018 (EST)
I had found the name of the OCLC verifier useful - they are usually the source of a lot (if not all) of the information in the record and additional questions often find answers by asking them when there is no PVs or when they are inactive. So I will be reluctant to lose or stop recording this information... Annie 23:27, 21 December 2018 (EST)
Interesting. I recall occasionally using secondary verifications in a similar fashion, but I didn't realize that it was a common practice. Just goes to show how different different editors' workflows can be. I guess we'll revisit this issue once we wrap up these 2 cleanup reports.
It also raises a larger issue -- how do we make "publication history" available to editors? A while back we added "My Recently Changed Primary Verifications" to our toolset, but it's more of a notification mechanism. There was an early attempt to create a general-purpose "Edit History" system, but it failed because our submissions do not capture "before" and "after" states. There is an outstanding request to Create a history of changes to primary-verified publications by storing a snapshot of the way each verified pub looked like right before it was changed, but it's also limited to primary-verified pubs.
One possible "low-hanging fruit" that comes to mind is linking Publication records to the submissions that originally created and subsequently modified them. We can easily do it for "New Publication" submissions because we added a "New Record ID" field to the submission table a few years ago. Linking to "Edit Publication" submissions is currently impossible because submissions do not store the IDs of the publications that they modify in a structured manner. However, it should be possible to extract them from the body of each submission and create a new field. Food for thought. Ahasuerus 13:32, 22 December 2018 (EST)
I had been working on a lot of housekeeping tasks so I probably had edited a lot more publications I am not verifying than most editors had. Which is probably why I've need to discuss something with a secondary verifier (and not just OCLC - the whole board of secondary verifications). Not sure how common it is in a "normal" workflow... :)
For the publication history: That will still have the problem with tracking the editing of titles - a lot of the changes in a publication are not done from the pub page but in an underlying titles - and we still have a blind spot there. While tracking the pub changes will be useful, it will be incomplete in showing the full story of what actually did happen. And with titles jumping pubs occasionally, it can get progressively harder to track the history (although we do have timestamps so we know when something is moved in or out). But yeah, if we can see who edited, we do not need a name on the verifications... Annie 15:33, 22 December 2018 (EST)
Oh sure, a "publication edit history" limited to New/Add/Clone edits would be incomplete. Still, I suspect that it would be a significant step forward and shouldn't be too hard to implement. It would also be retroactive since we would be linking all 2006-2018 submissions to their publication records. On balance, it may be a cost-effective palliative solution. Ahasuerus 16:20, 22 December 2018 (EST)
:) I agree, it is better than what we have now - and things get built step by step. Can we easily add import and removeTitle (both to the "Changed" list and to this? Those are always tied to the publication as well - it at least gives us one more of the actions. I know that merging and deleting may make these a bit hard to track but still... maybe even the ones that are around will be a good enough help... Annie 17:15, 22 December 2018 (EST)
Good point. FR 1237, "Enhance 'My Recently Changed Primary Verifications'", has been created. I have also created FR 1238, Create an Edit History page for publications. Ahasuerus 15:03, 26 December 2018 (EST)

Capturing Non-Linking Secondary IDs in a Structured Way

(Copied from ISFDB:Moderator_noticeboard#Capturing_IDs_in_a_Structured_Way -- see the sub-section at the bottom for my proposal.)

Original Discussion

One other advantage of having these [non-linking secondary] IDs in the database is that their presence makes it possible to check for gaps in our coverage. Since Reginald used sequential numbers (000001 through 37651) for first editions, we could easily create a cleanup report to look for gaps. Of course, it would be even easier to implement and display if we captured these IDs in a more structured way. Ahasuerus 16:49, 18 December 2018 (EST)

So are we back to "Let's have a non-linking External IDs" in their own list? And these will be extremely easy to move programmatically - they are very well (and predictably) structured in their notes - almost always alone on a line - so we can parse and dump the line... :) Annie 18:31, 18 December 2018 (EST)
I can think of two different programmatic solutions:
  • Create a new set of fields that would be similar to the "External IDs" box but without the linking
  • Modify the logic behind External IDs to allow non-linking IDs
The second solution would be much easier to implement. I suspect that it would also be more intuitive for users and editors. Ahasuerus 22:00, 18 December 2018 (EST)
I'd vote for the second approach. It also has the built-in capability to switch non-linking to linking with a simple server edit (as opposed to some type of reclassification depending on the design). Annie 22:19, 18 December 2018 (EST)
In theory (I'm sure this isn't practicable) it'd be nice to have IDs associated with the secondary verification checkboxes. The numbers that people are defending the usefulness of are ones where the book itself was considered useful enough to add to secondary verifications. In the case of Reginald, it would be very nice to have the reference number displayed next to the verification; more complicated in the case of OCLC where there can be multiple numbers. We have many OCLC numbers without Worldcat verification checked and vice versa, and it's somewhat redundant to have both. --Vasha (cazadora de tildes) 18:33, 18 December 2018 (EST)
Interesting points, some of them in line with what I have been thinking. I will mull it over and respond tomorrow. Ahasuerus 22:44, 18 December 2018 (EST)
Most of the external IDs are defacto verifications anyway - just not against the usual American sources and we do not keep record of who added them... For a Russian book I am much more likely to trust and check FantLab than OCLC and most of the information will come from the Russian source. Same for SFBG for Bulgarian, DNB for German and so on. And most editors had treated these as verification sources - by noting differences between sources. Just saying... Annie 23:20, 18 December 2018 (EST)
I wonder how it'd look to have both external IDs and verifications in the same section. Some sources of data would be numberable, some verifiable, and some both; some numbers would be linking and others not. Would just need suitable design to be legible. --Vasha (cazadora de tildes) 23:32, 18 December 2018 (EST)
I have just deployed a couple of cleanup reports to look for discrepancies between OCLC verifications and External IDs. It's a good example of how the two types of data are related.
Having said that, the two sections currently capture somewhat different types of data. Obviously, the External ID section captures linked IDs, which is very useful. On the other hand, the Secondary Verifications section lets you choose "N/A", which the External IDs section doesn't support at this time. It also records the date of the verification and the name of the verifier, which can not be changed except by the verifier. Also, unlike External IDs, verifications can be added without moderatorial oversight. I have also noticed that some editors become attached to their verifications.
I think tighter integration between External IDs and secondary verifications is worth considering. We just need to figure out how to reconcile the differences that I outlined in the previous paragraph. Ahasuerus 19:48, 19 December 2018 (EST)
The two don't have to be "linked" in order to be displayed together; it could be more like two parallel columns --perhaps start the left column with external IDs that don't have verifications, then begin a column of verifications on the right, with matching numbers associated on the appropriate line on the left. Just a thought.
As for better data entry linking, one possibility would be to have a space to enter an associated number on the 2ndary verification form (OCLC having a "+" for multiple numbers). The numbers would be sent to a moderated submission but the verifications would just go through automatically. --Vasha (cazadora de tildes) 20:08, 19 December 2018 (EST)
I've been reading through the historical material (well, tried to), and it seems to me the current dispute could be solved by adding non-linking external ID's. Why not be pragmatic, and implement the 2nd proposal from Ahasuerus (ie Modify the logic behind External IDs to allow non-linking IDs)? It wouldn't really change anything from the current practice. After all, we're already adding oclc's and check the corresponding verification flag. I can't imagine that that would be a lot of effort (but what do I really know about coding the ISFDB, right? :)). Granted, that wouldn't all that be efficient, but hey, it would be a start and better than what we have now. As for the integration of verification and referencing, yes that could (should?) be done, but as a future enhancement as I'm sure that that would cost considerably more dev'pment effort.
Again, if this non-linking ext ID thingy can be implemented 'quickly', I believe it'd bring back tranquillity to the community (or at least has the potential to), don't you think? MagicUnk 06:27, 20 December 2018 (EST)
There is always a balance between:
  • going after the "low-hanging fruit" which can be done quickly but may have to be reworked later on, and
  • implementing a long-term solution which takes longer to implement but is more likely to be permanent
An important factor to consider is whether a short-term solution would require more work down the road once a permanent solution is put into place. For example, the way we handled non-English titles prior to 2011 required a complete revamp once language support was added.
In this case allowing non-linking External IDs for Reginald, Bleiler, etc appears to be a low-risk proposition. Even if we end up implementing a different solution at some future point, it should be easy to move structured IDs to a different field(s).
In addition, we may want to have support for non-linking External IDs for other reasons. For example, if an external database were to go off-line, our links would become dead and would need to be deactivated. We wouldn't want to delete the IDs in case the site is eventually resurrected, but there are examples of bibliographic sites getting merged (like Shelfari) or becoming frozen (like the European Library.) Conversely, it's possible that some secondary sources may become available online at some point in the future.
For these reasons I think it would be worth adding support for non-linking External IDs sooner rather than later. We currently have around 4,000 Reginald IDs in Notes. It would be better to migrate them to a separate field while the number is still manageable. I will copy this proposal to the Community Portal where more editors will have a chance to eyeball it. Ahasuerus 16:21, 20 December 2018 (EST)
Two comments:
1. The suggested cleanup report looking for gaps makes sense for the Reginald, though we wouldn't catch variant titles that have an alphabetic suffix, which the proposal seems to be aware of. For the Bleiler indexes, this makes less sense. Bleiler indexes both books (novels, chapbooks, collections and anthologies) and stories. While the stories generally give their first or first few magazine appearances, I don't think it would be appropriate to add the catalog number to the magazine. If we were to do so, there are some magazine issues that would need to hold several catalog numbers. Those numbers are more title based by our definition. Consequently, gaps in numbering from publication records would be expected. As would duplicates (for books), as sometimes several editions are listed under a single catalog number. --Ron ~ RtraceTalk 21:40, 20 December 2018 (EST)
Thanks for the clarification! Since different references have different numbering schemes, I assume that the projected cleanup reports will have to be reference-specific. Some will be limited to looking for duplicate IDs (and support the "ignore" functionality) while certain others will also look for duplicates. Ahasuerus 13:09, 22 December 2018 (EST)
2. The Bleilers that contain catalog numbers are Supernatural Fiction, The Early Years and The Gernsback Years. Neither Bleiler78 nor its precursor number their entries.
Thanks. --Ron ~ RtraceTalk 21:40, 20 December 2018 (EST)

Capturing Non-Linking Secondary IDs in a Structured Way -- Proposal

Based on the discussion above, I would like to propose that we add non-linking IDs like Reginald-1, Reginald-3 and (some?) Bleilers to the list of supported External ID Types. It would require some changes to the software, but I believe that it shouldn't be too difficult to do. Ahasuerus 16:55, 20 December 2018 (EST)

I strongly agree with the proposal. Annie 17:15, 20 December 2018 (EST)
Agree. MagicUnk 17:48, 20 December 2018 (EST)
Agree also. --Vasha (cazadora de tildes) 18:09, 20 December 2018 (EST)
I also support this. --Ron ~ RtraceTalk 21:20, 20 December 2018 (EST)
Yes, please. Stonecreek 01:25, 21 December 2018 (EST)
Agree. Rudam 08:28, 21 December 2018 (EST)
I support this. --Chris J 15:35, 21 December 2018 (EST)
Pile-on support. ···日本穣 · 投稿 · Talk to Nihonjoe 16:10, 21 December 2018 (EST)
Another yes from me. PeteYoung 20:17, 21 December 2018 (EST)

Support for Non-Linking Secondary IDs -- Outcome

Consensus reached. FR 1236 "Allow non-linking External IDs" has been created. Ahasuerus 13:05, 22 December 2018 (EST)

How to handle PODs?

Hi, I was wondering whether Open Road Media is a POD publisher? I have The Goblin Reservation from Clifford D. Simak, and on the last page there are the following codes: BVHW07s0858081018, and, 529577BV00001B/146/P. From the former I deduce a printing date of 2018-10-08, and the second indicates POD (it has the same structure as confirmed Amazon PODs). Correct? My second question is, how do we best enter and verify POD publications, as there seems to be no guidance available yet for PODs? Obviously, a pub per print date (when available) is impractical. Would we update a pub, and add printing info like the codes above in one single pub, referring to the PVer and his copy? MagicUnk 04:39, 25 December 2018 (EST)

Open Road is a POD publisher, yes. They are doing a lot of reprints (they started only as e-book publisher I think and then just branched out). The last time we had this discussion, we kinda decided to consider all printings of PODs the same publication as long as nothing but those codes and dates change (same cover, same author version and so on). Adding the codes in the publication does not make sense - there may be thousands of them for popular books... I think we are still waiting and watching the situation. When I am cataloging POD books, I mention in the notes that it is a POD book but that's pretty much it. Annie 04:56, 25 December 2018 (EST)
There's the remaining question of printing dates; do we want to capture the printing date, and other related info, of verified PODs, as the verified copies are limited in number (for now). It would have the advantage of gathering data and keeping it with the publication. We can always go back and clean up later when we settle on how to handle PODs, right? See also the Binti case below. MagicUnk 04:55, 27 December 2018 (EST)

Binti

There's also the Binti case (and maybe other TOR chapbooks too). So far, the following information is available:

  • Binti - chapbook with standard print runs (first, fifth, eight, tenth, thirteenth have been listed so far). No evidence of POD. Nihonjoe and/or Hitspacebar may want to chime in with additional info on their copies.
  • Binti: Home - chapbook, all seem to be PODs, but with different 'characteristics'. The following info is available:
    • POD with First edition: January 2017, and P1 on the copyright page, and date and sequence numbers and 'Printed in...' on the last page (MagicUnk and Bluesman's copies)
    • POD without any of the numbers, nor P1 on its copyright page, only 'Printed in the USA' on back cover (Hitspacebar's copy)
      I've asked Nihonjoe to check his copy.
  • Binti: Night Masquerade - novel, seems to be a mixture of standard print-runs, and POD. Following info available so far:
    • First printing, full number line, no POD info whatsoever (MagicUnk's copy)
    • POD info, such as "Printed by BoD in Norderstedt, Germany" on top and has a QR code on the lower left corner - not sure whether there's the date code and/or sequence number too (Hitspacebar's copy)

As stated by Jens, it looks like at least TOR does a mixture of regular print runs and print-on-demand. I would suggest to make that distinction in the pub records too: ie have at least two records to distinguish POD from regular printings:

  • a record for all PODs, and - as Jens put it "I guess we should record in the note of the current record that copies are maybe POD and, as long as we can't clearly distinguish the different prints, also add all information (like the "P1" and the long sequence of letter numbers on the last page) to the note. Jens Hitspacebar 07:17, 31 March 2018 (EDT)"
  • and a record for the regular print runs.

Does this makes sense? MagicUnk 04:55, 27 December 2018 (EST)

Performance - 2018-12-26

I am aware of the performance issues that we have been experiencing today. As near as I can tell, they are being caused by a number of robots (Google, Bing, SemrushBot, etc) crawling the site at the same time. I am working on it. Ahasuerus 18:46, 26 December 2018 (EST)

I have identified the culprit. A rogue bot was running a custom Advanced Title Search which was designed to scrape a subset of our titles. It was also hiding that it was a robot. A rather odd thing to do considering that our backups are publicly available, so there is no need to scrape Web pages.
I'll create an SR to restrict Advanced Search selection criteria. Sorry about the aggravation. Ahasuerus 20:27, 26 December 2018 (EST)
Advanced Search is visible from pretty much any page, you need to know about the archives (or search the wiki) to find them. So not really surprising that someone will decide to go with Advanced Search... Thanks for finding the problem quickly :) Annie 20:46, 26 December 2018 (EST)
Good point. It may be best to add a note to the Advanced Search Page. Ahasuerus 20:57, 26 December 2018 (EST)
Is it back to doing it again? It seems that some queries are slowish again - almost the same way they slow down when the nightly reports run and how it felt earlier today. Annie 21:43, 26 December 2018 (EST)
Yes, that robot is back and running the same search. It's up to record 131,000 now. I'l see if I can do something about it in the short run. Ahasuerus 21:59, 26 December 2018 (EST)
I have tweaked our access settings to ban this particular bot temporarily. Ahasuerus 22:33, 26 December 2018 (EST)

(unindent)Is the not so intelligent bot back? Annie 18:36, 28 December 2018 (EST)

It is. It's also using VPNs to avoid getting blocked. I am looking into. Ahasuerus 18:43, 28 December 2018 (EST)
P.S. The underlying problem is that our Advanced Search software lets users create almost arbitrarily complex queries which then require traversing and examining hundreds of thousands of title records. While a query is running, all title records are locked, which makes all Web pages that display titles pause for up to 10 seconds.
Ideally, we would change the Advanced Search software not to lock records while running. Unfortunately, our database settings do not support this functionality.
Alternatively, we could impose additional restrictions on Advanced Search selection criteria, but it would make Advanced Search less useful. I'll need to think about the trade-offs involved. Ahasuerus
Have a separate Advanced Search for logged in and non-logged in users? The non-logged ones limits the criteria and the logged in one doesn't? -- JLaTondre (talk) 18:54, 28 December 2018 (EST)
An interesting thought. Thanks. Ahasuerus 18:57, 28 December 2018 (EST)
I'm not fond of that idea--why should one bad actor force everyone to have to log in in order to search properly? --Vasha (cazadora de tildes) 10:54, 29 December 2018 (EST)
Several of the sites that I use regularly require a log in to use advanced search, possibly for the same reasons.--Rkihara 11:48, 29 December 2018 (EST)
Because it's better than everyone being impacted as is the current case. -- JLaTondre (talk) 12:28, 29 December 2018 (EST)
Plus our accounts are free and do not require an email or verification - anyone that really wants to search can create one in seconds. Google search does not require one, simple search and even some advanced search options will still remain open. And we do not have unlimited resources and allowing the server to go down just because we are trying to be nice is a bad idea. Annie 14:31, 29 December 2018 (EST)
Can bots have logins? ../Doug H 14:53, 29 December 2018 (EST)
Technically? Yes - which is why so many sites use CAPCHA and similar things (among other reasons). But most bad actors tend to move on when they are asked to have a login as opposed to coding a login into the bot. Although if they are really persistent, coding the bot to create a new account and then do the search is not going to be too hard (and it is being done daily on sites that require a login for everything). Annie 15:02, 29 December 2018 (EST)
Also can add a requirement to have a handful of approved edits before enabling the more complex features. -- JLaTondre (talk) 16:32, 29 December 2018 (EST)

(unindent)And it seems like it is a very persistent bot - the site is sluggish again... Annie 14:34, 29 December 2018 (EST)

It was active earlier today, around 8-9am EST, and kept switching IP addresses -- I had to play whack-a-mole with it for an hour. It's usually active a few times a day, usually in the morning and in the early evening EST. I suspect that it requires manual intervention to change IP address and the operator is only available sporadically. It seems to be on hiatus again. Ahasuerus 15:17, 29 December 2018 (EST)
Yeah, it is back to normal - the site was a lot slower a few minutes before I posted above (almost as bad as it was when you were chasing that bad cleanup report a few weeks ago - definitely slower than on the last 2 days - or I just happened to be on the same titles...). I just wish we could just point the guy/gal to the archives... Annie 15:24, 29 December 2018 (EST)
I need to add a link to the backups to the Advanced Search page. Too many balls in the air at the moment... Ahasuerus 15:28, 29 December 2018 (EST)
At this point, probably wouldn't be seen as they already have the parsing logic and probably not looking at the page itself. Though of course, you could always tweak the layout to break their parser so they would have to check. Can you tell from the queries whether they working their way through something that should eventually end? Or are they just being intentionally disruptive? -- JLaTondre (talk) 16:32, 29 December 2018 (EST)
The query says "Find all titles that are not ESSAY or INTERIORART and that were first published between 1900 and 1999; sort by date." They have scraped 245K out of 562K eligible titles, so they are almost 50% there. Of course, it's possible that they will then change their query to cover 2000-2019 titles. Ahasuerus 16:54, 29 December 2018 (EST)

(unindent) The Advanced Search page has been linked to ISFDB Downloads. Ahasuerus 15:44, 31 December 2018 (EST)

Rod Serling

(copied from Talk:Awards)

The Rod Serling Memorial Foundation issues annual awards (complete with plaque!) Whom would I petition to have this award added? Thank you! —The preceding unsigned comment was added by Galacticjourney (talk • contribs) .

According to the award page:
  • The Rod Serling Award for Advancing Social Justice Through Popular Media honors a contemporary media industry professional whose work shines the light on prejudice, inequality, and evolving social norms.
Awardees:
  • 2015/2016: David Simon, a TV writer/producer none of whose TV credits appear to be speculative. Not in the ISFDB.
  • 2016/2017: Kenya Barris, a TV producer/writer none of whose TV credits appear to be speculative. Not in the ISFDB.
  • 2017/2018: David E. Kelly, a TV producer/director none of whose TV credits appear to be speculative. Not in the ISFDB.
  • 2017/2018: Bill D'Elia, a TV producer/writer none of whose TV credits appear to be speculative. Not in the ISFDB.
  • 2018/2019: Norman Lear, a TV producer/writer. His media credits are extensive, but I can't find anything speculative. We have one essay (published in Omni) on file.
Considering the fact that this award is for media (as opposed to written) work and that it's not related to SF, I don't think it falls within the scope of the project. Ahasuerus 15:46, 28 December 2018 (EST)
I would have to agree with Ahasuerus. If anyone listed on ISFDB ever wins one, it could be placed in the bio notes on the author/artist page. ···日本穣 · 投稿 · Talk to Nihonjoe 17:24, 28 December 2018 (EST)
I think you may be looking at the wrong Serling Awards: 2016 and 2017 :) --Galacticjourney 22:55, 28 December 2018 (EST)
Oh, I see. Checking the lists of awardees, I see:
  • 2016:
    • A blog about the history of science fiction with an emphasis on The Twilight Zone
    • An abstract film
    • An album inspired by a Twilight Zone episode
    • A podcast inspired by The Twilight Zone
  • 2017:
    • An anthology collecting 22 stories in the tradition of The Twilight Zone, which we have on file
    • A documentary related to a Twilight Zone episode
    • A musical record inspired by The Twilight Zone
Of the 7 awards, 6 are for media works with links to The Twilight Zone and one is for an anthology of stories related to The Twilight Zone. Since only one of the awards is for written speculative fiction, I think the best approach would be to document the award in that record's Note field. Ahasuerus 08:41, 29 December 2018 (EST)

Galactic Journey

We have a new editor that would like to add the Galactic Journey as a web fanzine. It does not appear to me to meet our online periodical criteria. However, it was nominated for Hugo in the fanzine category this year. As such, I would like to get a wider opinion than basing it solely on mine. -- JLaTondre (talk) 20:42, 28 December 2018 (EST)

The good JLaTondre invited me to join the discussion. The Journey won the Serling Award in 2016 and was a Hugo finalist in 2018. There are some twenty staff associated with the organization, many of whom are professional SFF authors, and articles are published every other day. It is at least as notable as some of the fanzines currently listed on ISFDB. Thank you for your consideration! :) --Galacticjourney 22:06, 28 December 2018 (EST)
It seems this should be "in" under the Online publications available exclusively as a Web page, but only if: ... shortlisted for a major award clause. How exactly to fit a blog-style publication into our data model is a wee bit of a challenge. Maybe treat each post as an "issue", along the lines of how we'd treat a daily print periodical? There are post-specific links, and each post has a date and author credit. How we'd link awards that are for the entire "publication", I don't know; I suppose we could make a collection to represent the entire year and link the award to that. --MartyD 12:33, 29 December 2018 (EST)
That clause though is under the fiction heading. I'm not seeing any fiction for this site. Seems to be mainly reviews and commentary? -- JLaTondre (talk) 12:42, 29 December 2018 (EST)
There are a thousand articles at the Journey...that'd be a bit of a headache. :) Maybe just an annual entry with notations as to awards won that year? You are correct that there is no fiction, except that the whole thing is somewhat fictitious (it's a fanzine written as if by people living 55 years ago). I do greatly appreciate your stretching brains to figure out how to make it fit! :) --Galacticjourney 15:57, 29 December 2018 (EST)

As there has been limited discussion, I have released my hold on this record. I'll let another moderator make the decision. -- JLaTondre (talk) 19:13, 4 January 2019 (EST)

More Charles McCarry

I love the novels of Charles McCarry, a great thriller/spy/politico/alternate-universe writer. We currently have a listing for him with, I think, five "Christopher Series" works listed. There are at least another four and maybe five that fall within that description, plus at least one novel that is clearly science fiction. I'll start putting these in as I get around to it. Hayford Peirce 10:16, 29 December 2018 (EST)

The Italian edition of my novel Napoleon Disentimed is NOT a serial

For some reason this novel is listed as being a serial. See http://www.isfdb.org/cgi-bin/title.cgi?1034444. I just pulled down my copy from the shelves and it is exactly as listed here, Urania 1135, Complete Novel, etc., but it is a stand-alone issue, with no other stories or anything else in it. In other words, this edition looks *exactly* like the publication of an entire novel. As I've only just returned to this site after being away for a number of years, I'm not sure what to do about this, so I'm bringing it to your attention here. If there is some other place on the site that I should have used, please let me know. Thanks! Hayford Peirce 12:29, 29 December 2018 (EST)

You've just discovered one of the quirks of this database. It was decided long ago that we would never assign anything in a magazine the title type NOVEL--instead, when a novel appears in a magazine, it has the title type SERIAL, whether it is published in several parts or just one. See Help:Use of the SERIAL type#"Complete Novel" rule for a discussion of the reasons behind this decision. --Vasha (cazadora de tildes) 12:42, 29 December 2018 (EST)
Cross-posted with Vasha's much more succinct response above. In case any of this detail is helpful: If a novel is printed in a magazine, we consider it a "serial", even if printed in its entirety in a single issue, with no other content. That is still technically an issue of the magazine, containing the novel, rather than the novel's publication as a "book". We then make a variant of that "serialization" title to a non-serial title, which ultimately shows where the work was published in magazines and where it was published as books. You can see the result here. The presentation in the Fiction Series section here is a little clunky with the combination of Serialization: and Translation: and lack of indentation, but still seems to convey the proper information -- the Italian translation appeared as a complete novel in a magazine. It all looks ok to me. What problem is it causing? --MartyD 12:47, 29 December 2018 (EST)
Thanks for all the above info. Until now I had no idea that Urania was a magazine and not a book series. No problems involved, of course, at least not after knowing the above. Hayford Peirce 13:58, 29 December 2018 (EST)

Adding External ID for the Belgische Bibliografie?

I recently submitted a number of pubs of Belgium publishers to add price in Belgium francs and added the URL of the source (De Belgische Bibliografie) in the notes. It then occurred to me that that is rather stupid as we (well, that's Annie actually :) recently finished cleaning up the notes and moved OCLC links to the External ID field. Is it quick to do to add these permalinks for the De Belgische Bibliografie/La Bibliographie de Belgique? If so, I'll refrain from further updates until the External ID has been added. Example: https://opac.kbr.be/Library/doc/SYRACUSE/15789982/. The External ID is the number at the end of the URL. MagicUnk 15:02, 29 December 2018 (EST)

Adding a new External ID Type is fairly straightforward. Are we sure that the URL scheme is stable? Ahasuerus 15:31, 29 December 2018 (EST)
I's say, yes, it is stable. If you hover over the little chain link to the right of the example above, the tooltip text says permanent link (new window). MagicUnk 15:55, 29 December 2018 (EST)
That should be good enough for our purposes. FR 1241, "Create a new External ID Type for De Belgische Bibliografie", has been created. Ahasuerus 16:12, 29 December 2018 (EST)
Make sure we have a matching template - we missed that for a few of the External IDs. :) Annie 16:22, 29 December 2018 (EST)
Oh, right. What should we call it? Ahasuerus 16:43, 29 December 2018 (EST)
The official name (in two of the official languages) is "Bibliothèque royale de Belgique"/"De Koninklijke Bibliotheek van België. With the site being kbr.be, we kinda have a choice. If noone else has a preference, KBR sounds good to me - thus not chosing between the language versions (BRB abd KBB)... Or we can go with BB which will be language agnostic but will be very very confusing with the other external identifiers (in my humble opinion). Annie 16:54, 29 December 2018 (EST)
(after edit conflict) Small tidbit of info. Since Belgium is a bilingual country the name of the bibliography is to be in Dutch and French, so it's De Belgische Bibliografie/La Bibliographie de Belgique (actually Belgium is trilingual as German is the third official language, spoken in the east of the country near the German border). There seems to be no official abbreviation. We could use BB, which would nicely fit both Dutch and French. MagicUnk 16:55, 29 December 2018 (EST)
After reading Annie's post, KBR sounds good too. While KBR references the Royal Library instead of the bibliography, it would solve the confusion with other Ext ID's when using BB. Or we could have BeBiBe ... :-) MagicUnk 17:00, 29 December 2018 (EST)
KBR works for me. If there are no objections, I will implement it once I wrap up Fixer's submissions for the month. 57 ISBNs to go... Ahasuerus 09:50, 30 December 2018 (EST)
Sure, np. MagicUnk 11:22, 30 December 2018 (EST)

(unindent) KBR has been added to the list of supported External Identifier Types. A matching linking template has been added. If you run into any issues, please let me know. Happy New Year! Ahasuerus 18:01, 31 December 2018 (EST)

Thanks Ahasuerus. Mosr appreciated! MagicUnk 04:06, 1 January 2019 (EST)
Thanks! 31 publications have the direct link. I will clean them out and move the IDs to their new house :) Annie 18:21, 31 December 2018 (EST)
30 converted, 1 remaining that is not like the others. I will look at it later unless someone can figure it out faster :) Annie 18:47, 31 December 2018 (EST)
You're too quick Annie, you beat me to it :). Thanks for the conversion. I'll have a look at the remaining one. If you could provide me with the pub reference? MagicUnk 04:06, 1 January 2019 (EST)
I just happened to be around :) The "31 publications" link in my previous message now points to the only remaining one but here is the direct link as well :) Annie 04:45, 1 January 2019 (EST)
Submitted the fix! MagicUnk 05:05, 1 January 2019 (EST)

(unindent) Now that the dust settled, can we add KBR to this report? Annie 16:09, 3 January 2019 (EST)

Done! Ahasuerus 17:49, 3 January 2019 (EST)

Belgium Francs - abbreviation?

Related question: what abbreviation should I use for Belgium Francs? I've browsed the internet, and a number of different options are available: the ISO code (BEF), or alternatively Bfr. ? I've also come across simply fr., or BFR, or BFr. ...? MagicUnk 15:02, 29 December 2018 (EST)

There's no real consistency. You should not use BEF (the ISO code). We intend that the "symbol" be used. I think for francs, this is "fr", although I know we have extensive use of "F". The "$" case provides precedent for applying a country-specific modifier on what would be an ambiguous symbol (e.g., "A$" for Australian dollar prices). So I'd be inclined to use "Bfr". And we include a space after any non-symbolic currency "symbol", so, for example, "Bfr 123". --MartyD 17:58, 30 December 2018 (EST)
Thanks. That makes sense. Would we benefit from keeping a list of currency symbols in the help text? We would then be able to, say, 'officialize' use of C$ for Canada, Bfr for Belgium, etc. Anyone else any thoughts? MagicUnk 03:53, 31 December 2018 (EST)
The list of the more popular ones (when the help page was written anyway) is already there - including the Canadian dollar. This is the help page for the price field - there is a lot of interesting information in these help pages even for fields taht appear clear. Adding some new currencies to the list is probably a good idea :) Annie 04:16, 31 December 2018 (EST)
Ah, yes... Would it be OK to add Bfr and ƒ (for Dutch Guilders) to the help text? MagicUnk 06:50, 31 December 2018 (EST)
Spanish peseta is Pta, Mexican dollar is Mx$. Question: since Argentinian peso is Ar$, should we change the Australian dollar to Au$? That is the form you always see in actual use, anyway. --Vasha (cazadora de tildes) 15:13, 31 December 2018 (EST)
Changing the Australian dollar is a bad idea -- we have thousands of publications with it and everyone is used to using it. So no, I will vote strongly against changing it. Otherwise we should change the good old US dollar to U$ or something :) Let's leave the established symbols alone. Annie 18:19, 31 December 2018 (EST)
Once we start working on adding support for multiple prices per publication (FR 1158), it will be a good time to revisit the issue of currency symbols. The proposed redesign will make them table-driven, so changing currency signs will require a single database update per currency. Ahasuerus 18:26, 31 December 2018 (EST)
True. I was commenting on the situation now when people need to remember how to write certain currency symbols. If and when we redesign the whole thing, we can discuss again what/how we want to be shown. But swapping a well-established symbol that is used a lot just does not make sense. :) Annie 18:30, 31 December 2018 (EST)
I went ahead and updated the help text with Bfr, ƒ, Pta, Mx$, and Ar$ examples. Let me know if it isn't acceptable.
Also, I have been thinking about pubs that have more than one price, and how we can ease the migration effort once FR 1158 becomes available. Currently we record the primary price (ie price in country of origin) in the price field, and the secondary prices in the notes field. Would it be a good idea to have templates for the most common currencies that show up in the notes, such as $, C$, A$, £, Bfr, ƒ,..., and also request editors to effectively start using them? If we would start using templates, I'm sure that the conversion would become much easier, no? MagicUnk 04:58, 1 January 2019 (EST)

a "known phishing site"

When I come to ISFPB from my destop screen, I go first to the Home Page. Then I click on ISFDB Wiki. From there I go to Community Portal, which is where I'm writing this. If I have just done this for the time, ie, starting with the Home Page from my computer desktop, a small box pops up on the lower right of my screen courtesy of Emsisoft, my excellent Anti-Virus program.

Its mysterious message is, more or less: "www.audible.co.jp is a known phishing site and we have blocked it". After about ten seconds the box slides away and I am unable to get a screen shot of it to show you.

As far as I know, Emsisoft is an *excellent* AV program, one that is both alert and yet NOT overly intrusive.

Is there some reason that it seems to feel that some aspect of ISFDB is a phishing operation? It's very, very rare that I get a message like this. It's all very mysterious to me! Hayford Peirce 15:37, 30 December 2018 (EST)

There is a reference to audible.co.jp in this discussion on the page. Your antivirus must be detecting the presence of links to the site. ../Doug H 15:56, 30 December 2018 (EST)
According to this PCmag.com review, Emsisoft offers "excellent" malware protection but "dismal" phishing protection. It detected only 18% of the phishing sites that PCmag tried in their October test.
Another thing to keep in mind is that the ISFDB allows links to arbitrary Web pages in notes and "Web Page URL" fields. Granted, all submissions are reviewed by moderators and are most likely safe at the time when they are approved. (Also, submissions by new editors are flagged.) However, the internet is a rapidly changing environment. Author-run sites are frequently abandoned and then purchased by third parties, some of them malicious. When it happens, our links can be affected. Ahasuerus 17:11, 30 December 2018 (EST)
Thanks for the lucid explanation. I have noticed before that Emsisoft doesn't seem to be up to speed with phishing in general. I THINK I can tell it to ignore this particular one, though. If I can, I'll do so. Hayford Peirce 17:28, 30 December 2018 (EST)

Support for non-linking External ID Types added

As per this discussion, the software has been updated to allow non-linking External ID Types. As expected, it was a fairly straightforward change.

The next step is to decide which non-linking External ID Types we want to add at this time. Here are the current candidates:

Anything else? Ahasuerus 18:42, 31 December 2018 (EST)

These look good to me for a start - and I cannot think off the top of my head of any other IDs that I had seen often enough to consider them eligible for pulling into an ID field. Annie 16:30, 1 January 2019 (EST)
OK, I have added the 5 non-linking ID types listed above. Here is an example of what a converted publication record looks like. If everything looks OK, I can create new cleanup reports to facilitate the conversion process. Ahasuerus 22:39, 1 January 2019 (EST)
Thanks for this. I don't know what I'm going to do with my templates now. --Ron ~ RtraceTalk 07:09, 2 January 2019 (EST)
Hey, they served their purpose! The new cleanup report that I deployed a few minutes ago takes advantage of the fact that these IDs were entered in a semi-structured manner to facilitate the migration process.
Once the cleanup reports are regenerated overnight, there will be 1,700+ publication records that will need to be updated. There are probably more since early on some IDs were entered in a non-structured fashion, but let's take care of the low-hanging fruit first. Ahasuerus 11:48, 2 January 2019 (EST)

(unindent) We probably should also add them to this report (with the Reginalds allowing a last alphabetical symbol) so we do not end up chasing them later when some typos happen. We probably will also want to have a check if it is in the proper range at some point (As these 5 are finite) but that is not as easy... Annie 16:11, 3 January 2019 (EST)

Do we know if the 3 numbered Bleilers use purely numeric record IDs? I have the Reginalds but not the Bleilers in my collection, so I can't check. Ahasuerus 18:10, 3 January 2019 (EST)
OK, the two Reginalds have been added to the cleanup report. Ahasuerus 18:55, 3 January 2019 (EST)
I suspect that Ron's books are out in the open and he can check easily - I do not remember seeing anything but numbers in either Gernsback, or the Early Years but both of them are in a box (and I have no idea which of the many boxes...) and admittedly I was not trying to verify if there is anything else there besides numbers. Annie 22:23, 3 January 2019 (EST)
Indeed they are. Bleiler numbers are all numeric for books. He does list the contents by letter within each anthology/collection by letter, but we wouldn't need to add that to a publication record, so a numeric test would be fine. --Ron ~ RtraceTalk 07:05, 4 January 2019 (EST)
Thanks for the confirmation. The cleanup reports have been updated. Ahasuerus 14:03, 4 January 2019 (EST)
I noticed something with this publication. Take a look at the first external ID which appears to have an extra space between the bullet and the number. It's possible that this is browser specific and I'm using Firefox. In any case, I fixed this by clearing an extra newline at the end of the notes. I put it back, for discussion. It's only a minor cosmetic issue, so not in any way urgent. Thanks. --Ron ~ RtraceTalk 07:28, 4 January 2019 (EST)
I have tried it under Firefox 64.0, Google Chrome 71.0, MS Edge 44 and IE 11 and I am not seeing the extra space. Could you please check which version of Firefox you are using? Ahasuerus 11:05, 4 January 2019 (EST)
I'm also running 64.0. A little additional testing finds that the extra space appears only from the View This Pub link from the SQL statements page. A refresh makes things appear correctly. Also no matter how I edit it, there appears to be one newline at the end of the note text, i.e. whether I remove the newline, or add a second one, when I go back in there appears to be a single new line at the end of the text. Given that the display rights itself on a refresh, I wouldn't worry about it. Also it seems that there may be some sort of cleanup of the notes field that puts a single newline in place of any trailing whitespace (I'm guessing). If this is by design or accident, it certainly seems reasonable. Sorry to have you chasing wild geese. --Ron ~ RtraceTalk 19:13, 4 January 2019 (EST)
Thanks for the additional information! I have been able to recreate the problem -- sort of. Under Firefox 64.0, the first displayed External ID is displayed with an extra space if the Notes field immediately above contains the "BREAK" template. The other tested browsers do not have this problem and even under Firefox it is somewhat inconsistent.
The underlying HTML code is valid as per the W3C validator, so I expect that it's an issue with Firefox 64.0. If the bug is not fixed in the next few versions, I may do more digging and try to come up with a workaround. Ahasuerus 21:25, 4 January 2019 (EST)
Retrieved from "https://isfdb.org/wiki/index.php?title=ISFDB:Community_Portal/Archive/Archive45&oldid=552192"