ISFDB:Community Portal/Archive/Archive45

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

---

Expanded archive listing

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 ~ Rtrace^Talk 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:

• The Hero of Varay: "by Keith Parkinson [as by Parkinson]"
• Die Rebellion des Schützen Cade: "(1971) • by Leo Dillon and Diane Dillon (variant of One Million Tomorrows 1970)"

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:

• Publisher-specific pages like User:Fixer/Public/47North
• Author-specific pages like User:Fixer/Public/Caleb Wachter
• Month-specific pages like User:Fixer/Public/2018-07

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:

• Editor Title: Apex Magazine - 2009 • [Apex Magazine] • (2009) • edited by Jason Sizemore [as by Jason B. Sizemore]

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:

• Editor Title: Apex Magazine - 2009 • [Apex Magazine (Issue Grid)] • (2009) • edited by Jason Sizemore [as by Jason B. Sizemore]

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

• はたらく魔王さま! / The Devil Is a Part-Timer (light novels)
• Понедельник начинается в субботу / Monday Begins on Saturday
• 魔法戦士リウイ (Rune Soldier)

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 ~ Rtrace^Talk 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:

• Les sortilèges de la nuit NOVEL/COLLECTION (done).
• Un monde magique NOVEL/COLLECTION (done).
• Siilo NOVEL/OMNIBUS
• Progetto Stelle NOVEL/COLLECTION
• L'homme venu du futur NOVEL/SHORTFICTION (done).
• L'échiquier fabuleux NOVEL/SHORTFICTION (done).
• Les revenants des étoiles NOVEL/COLLECTION (done).
• La chute d'Atlantis NOVEL/OMNIBUS (done).
• Silo NOVEL/OMNIBUS

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 ~ Rtrace^Talk 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 ~ Rtrace^Talk 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 ~ Rtrace^Talk 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)