ISFDB:Community Portal/Archive/Archive47

From ISFDB
Jump to navigation Jump to search

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

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


Python error

Was trying to add an image to an entry and got this python error: Image:Screen Shot 2019-07-13 at 7.28.13 PM.png. Oddly, everything seems to have gone through okay as the publiscation in question (723121 seems to be fine (it has the cover I uploaded). ···日本穣 · 投稿 · Talk to Nihonjoe 21:32, 13 July 2019 (EDT)

Got the same error again when updating the cover artist for this pub: 264000. ···日本穣 · 投稿 · Talk to Nihonjoe 21:35, 13 July 2019 (EDT)
That was an unintended side effect of the post-approval change discussed on the Moderator Noticeboard, now fixed. The bug only affected the way things were displayed, not the data added to the database. Sorry about that! Ahasuerus 22:50, 13 July 2019 (EDT)
No problem. You want the image deleted? I don't know if it has any potential security stuff in it. ···日本穣 · 投稿 · Talk to Nihonjoe 23:08, 13 July 2019 (EDT)
Nope, no security stuff. Just a graphic reminder to re-test all changes before installing them :-) Ahasuerus 23:18, 13 July 2019 (EDT)

Yiddish Speakers?

I added story by Der Nister which is a translation from the original Yiddish. While I can find a scan of the original Yiddish edition at Hathi Trust (Vol. I and Vol II, I was unable to determine the original title in the proper alphabet and thus added this title reflecting the Yiddish language parent but noting that the original title hasn't been found yet. Are there any editors that are fluent enough with Yiddish to find the proper title? The English title is "At the Border". I'll also note that the collection Gedakht is described by Wikipedia as a "collection of fantastic stories", and may itself be eligible for inclusion here if someone wants to take that on as a mini project. Thanks. --Ron ~ RtraceTalk 12:06, 14 July 2019 (EDT)

It looks like "Gedakht" is געדאכט, but that's all I can figure out. ···日本穣 · 投稿 · Talk to Nihonjoe 15:22, 14 July 2019 (EDT)
Google Translate says "At the Border" is אין די גרענעץ, but I have no idea how accurate that is. ···日本穣 · 投稿 · Talk to Nihonjoe 15:23, 14 July 2019 (EDT)
I searched the text for גרענעץ and found four entries: אויף גרענעץ, which apparently means "On (the) border", זיך א גרענעץ, which means "set a boundary", זיין גרענעץ, which means "its boundary", and קיין גרענעץ, which means "no border". One of those might be the title. ···日本穣 · 投稿 · Talk to Nihonjoe 15:30, 14 July 2019 (EDT)
According to Language help, Linguist knows a little Hebrew. It's not the same thing, but uses the same alphabet, so he might be able to offer some help. ···日本穣 · 投稿 · Talk to Nihonjoe 15:33, 14 July 2019 (EDT)
I think I found it. The table of contents in Volume 1 is on page 243. I carefully reconstructed the title of the story that appears on page 137 using the Hebrew alphabet Wikipedia page and ended up with אויפן גרעניץ which Google translates as "On the borders". Assuming that I identified the correct letters (exporting the scan to a pdf didn't work with cut and paste), I think I've identified the title correctly. Thanks again. --Ron ~ RtraceTalk 17:44, 14 July 2019 (EDT)
Saw the post a bit late. I have added a transliteration to the title : oifn grenits, the equivalent of German auf der Grenze « on the border ». Cheers, Linguist 05:19, 16 July 2019 (EDT).
Maybe you can add Gedakht to the database? You might be able to it more quickly than anyone else here. ···日本穣 · 投稿 · Talk to Nihonjoe 19:54, 17 July 2019 (EDT)
Will do (in due time, as there seems to be quite a lot to do…). Or maybe Ron can enter the romanized titles, and I'll Hebraize what I can ? Lekhaim ! (! לחיים) Linguist 04:43, 18 July 2019 (EDT).
I went ahead and took a stab at it. It would be an excellent idea for someone to check the entries against the scans to ensure I didn't get them wrong. Also to add missing transliterations. I also went ahead and made the Yiddish name canonical. I was able to link up all but one of the English titles. I suspect that "The Fool and the Forest Demon" may be "דער נאַר און דער ןןאַלד־רוח" as Google translates that as "The fool and the old age" which is a close title. Thanks. --Ron ~ RtraceTalk 18:35, 19 July 2019 (EDT)
I have linked "The Fool and the Forest Demon" and "נאַר און דער ןןאַלד־רוח, that was OK, and corrected the transliteration (der nar un der vald-rukh; you had confused ו (v) and ן (final n), which do look almost alike; and in Yiddish, א at the beginning of a word usually indicates it starts with a vowel, so און is just un “and” (= German und), not aun. I have started looking at געדאכט: ערשטער באנד : your first entry, the title of the story on p. 7, דער נזיר און דאָס ציגעלע, was written backwards (each word correct, but in the wrong place, if you see what I mean). I have corrected it, but there is one word I don't undestand : "The hermit and the stigele". Does that sound familiar ? Linguist 05:56, 20 July 2019 (EDT).
Same thing for the next one (words were inversed) : צוס בּאַרג, tsum barg = German zum Berg “at the mountain”. Linguist 07:41, 20 July 2019 (EDT).
Ditto for אין וואַלד, in vald, "in the forest" (German im Wald). Linguist 07:58, 20 July 2019 (EDT).
Went through both volumes, updated a few more transcriptions, gave translations when possible. There are two titles I don't understand fully, and three not at all. Sorry ! :o( Linguist 08:38, 20 July 2019 (EDT).

Votes and counting

I've been adding a lot of votes recently and have been amused at how, sometimes, my feeling about a story/book fails to match up with others' votes. Amused, but not surprised--we all read, and enjoy, different things. However, I do think it would be interesting in the Statistics/Top Lists to expose those stories that have the farthest deviation from the mean (i.e., stories that some people absolutely hated while others loved). The one I ran into today was Philip Jose Farmer's "Riders of the Purple Wage," originally published in Harlan Ellison's Dangerous Visions anthology. I thought the story was quite good, especially when re-reading it recently because the concept of a universal basic income has become more prevalent. It already had two votes when I added mine: a 1 star and a 4 star. Somebody really hated it. Gengelcox 16:24, 14 July 2019 (EDT)

It's certainly doable. A simple database query (select std(rating),title_id from votes group by title_id having count(user_id)>3 order by std(rating) desc) creates a list of controversial titles starting with:
Ahasuerus 18:29, 14 July 2019 (EDT)
That's exactly the kind of thing I was hoping might pop up -- I recall reading The Time Traveler's Wife with a book club and how it really creeped some readers out while others loved it. Gengelcox 10:20, 15 July 2019 (EDT)

On the subject of the Stats page and votes, I'm wondering if we could expose the top lists for novella, novelette, and short story along with the list already being run for novel? Gengelcox 16:24, 14 July 2019 (EDT)

We could create a "top" list for SHORTFICTION titles, which would include short fiction without a "length" designation. We could also create separate sub-lists for novellas, novelettes and short stories. Ahasuerus 18:29, 14 July 2019 (EDT)
I'd be interested, but obviously not a priority. Gengelcox 10:20, 15 July 2019 (EDT)
OK, FR 1289 has been created to document these suggestions. Ahasuerus 11:04, 16 July 2019 (EDT)

Jerry Ahern

Someone had started shifting the canonical name to a name that was never used in print (Frédéric Charpier for them (at least in our DB) and unless I am missing something, is not even connected to these books). Can someone share light on what they had been doing here (and add notes to the authors names). If noone can explain what this is all about, I will break the pseudonym in about a week and clean these pages up a bit. Annie 15:27, 17 July 2019 (EDT)

Apparently Charpier translated a bunch of Ahern books into French, then continued the series himself while continuing to use the Ahern name. At least that's what the French Wikipedia article states:

Frédéric Charpier a par ailleurs traduit en français un grand nombre de romans d'inspiration survivaliste de la série Le Survivant de Jerry Ahern (en), puis continué lui-même la série en français, sous le couvert d' « adapations » qui sont des créations originales (numéros 29 à 53, aux éditions Vaugirard).

Not sure if that's what this is about, but it's what I could find. ···日本穣 · 投稿 · Talk to Nihonjoe 16:07, 17 July 2019 (EDT)
This site seems to support what I wrote above. ···日本穣 · 投稿 · Talk to Nihonjoe 16:11, 17 July 2019 (EDT)
Aha. That explains it. Thanks - somehow I missed that when I was looking through the wiki articles earlier and trying to figure out what is going on. Why can't people just use their own names (I know, I know...). I will add some notes on the author's page... :) Annie 16:12, 17 July 2019 (EDT)
I'm the culprit (only saw the post today). As Nihonjoe explained, Charpier went on writing the series himself after translating the first ones, but indeed his name never appears except as a “translator / adapter” : a common practice among the Plon / Presses de la Cité / Vaugirard / Vauvenargues publications (see some of the Blade / Jeffrey Lord pubs, with a host of French shadow-writers). I thought I had made a general note somewhere about it, but had apparently only meant to… But such notes appear on each individual title, see here. And by the way, the Wikipedia passage quoted by Nihonjoe was written by me ! Linguist 04:15, 18 July 2019 (EDT).
Come to think of it, I had written the note for Original Richard Blade Adventures in French, but somehow the one about the Survivalist got waylaid. Linguist 05:23, 18 July 2019 (EDT).
Yeah, once I got on the right track, it started clearing up. Thanks for the explanation! I wonder if we should not use Jerry Ahern (Frédéric Charpier) for these books (or something along these lines) so it is clear it is not really Ahern - we had done that for other wrong attributions in the past. Annie 13:33, 18 July 2019 (EDT)
I would use "Jerry Ahern (II)" and include a note on the author page explaining things. ···日本穣 · 投稿 · Talk to Nihonjoe 14:45, 18 July 2019 (EDT)
That also works :) Even "Jerry Ahern (I)" would work. I find descriptive differentiator easier but the nummeric ones work as well. Annie 15:21, 18 July 2019 (EDT)
I like the numeric ones better because they are shorter. ···日本穣 · 投稿 · Talk to Nihonjoe 15:29, 18 July 2019 (EDT)


(unindent) Our software supports uncredited co-authors (e.g. see this series), but it doesn't have native support for ghostwriters. We have FR 346, "Add support for ghostwriters", but it wouldn't be easy to implement. For now, the best we can do is add a note at the author level like we have done with V. C. Andrews and her ghostwriter Andrew Neiderman.

Speaking of the "Richard Blade" series by "Jeffrey Lord", Wikipedia says:

  • In the early 1990s the Russian publishers could secure the rights to only the first six books in the series, and approached the translator - Mikhail Akhmanov - to write the further adventures of Richard Blade.[3] Together with then young sci-fi author Nick Perumov and others, Akhmanov wrote over sixteen sequels[4] to the adventures of Richard Blade, and then, after writing Russian sequels to the saga of Conan, went on to create numerous original characters and plots.

The Russian Conan project was apparently similar. Ahasuerus 15:30, 18 July 2019 (EDT)

Publication Series Name

Several hours ago the new publication series 8383 Queen's Treasure Series was created in the usual way, by adding its first publication record, which remains the only one. I added a pub series Note. Publication Series: Queen's Treasure Series. The keyword Treasure should be plural.

First Question: If the pub series name is modified in its one publication record, will the existing pub series record be deleted, and its information lost --either immediately on approval, or by some automated cleanup, perhaps overnight? (I understand that is the case when a publisher name loses its only publication record.) --Pwendt|talk 21:57, 17 July 2019 (EDT)

Publication series get deleted as soon as they loose their last book. This is one of the cases when you need to find a moderator and ask them to change the name. Which I just did. :) Annie 22:16, 17 July 2019 (EDT)
Thanks. So this one is now named "Queen's Treasure Series", which happens to be the name displayed on half-title page, rather than "The Queen's Treasure Series" as atop the description and list on the next page and in newspaper advertisements by the publisher. In some newspaper articles "Queen's Treasures" in quotation marks may be found.
Second Question: Do we have good reasons to prefer shorter or longer versions of names such as "[The] Queen's Treasures [Series]"? --Pwendt|talk 17:57, 18 July 2019 (EDT)
It's actually "Queen's Treasures Series" now - as requested :)
In a lot of cases, it is down to the editor's preference. The word Series is rarely in the name of a series I create for example - except for older series where I may add Series if I expect that someone can consider it a magazine. Or something. So... no real good reason - unless one specific spelling is used a lot more often in both books and reference materials. If I was adding it, I probably would have added it as "Queen's Treasures" but that is just me - and I would not change it when someone adds it the way you added it. Adding a note in all spelling being used (and where) is never a bad idea. Annie 18:18, 18 July 2019 (EDT)

Slow Server

Is it just me or is the server extremely slow at the moment? Annie 18:26, 19 July 2019 (EDT)

Facebook links

I'm guessing a fix was put in to allow links from Facebook to link correctly by stripping out the "&fbclid=" part. However, it looks like there's a tiny error still. The links come through with an equal sign (=) added to the end, so they still don't work. This link should go to 724848, but the equal sign prevents that. ···日本穣 · 投稿 · Talk to Nihonjoe 17:56, 24 July 2019 (EDT)

I don't recall any recent software changes that should have affected the way URLs are processed. Could you please post a sample "native" Facebook URL? Ahasuerus 22:10, 24 July 2019 (EDT)
They look like this:

https://l.facebook.com/l.php?u=http%3A%2F%2Fwww.isfdb.org%2Fcgi-bin%2Fea.cgi%3F134396%26fbclid%3DIwAR3OXAEyuHT1_DnUzX-Tcv034vhq_SK67RFSzaq9YPKJ-Rn0XK4sDu_e1no&h=AT3ko-M8HhxEAD8-AyA0tPcBCjgKDxL9prtGNFq-RVARTQoeLpsqJ3qmQuAuSSKwOYYGPkJl63JIBO_WyePJ7VehGAC_0QxggDWv-uOzULagbxUoyQq2eCiyf3jw_X3a2y6nXdZnMYgaXj_HFNiofqqf3xV_1nFkysIT-w-Q-NdK9PnjoR2-6Usdi8UkDKGAcfHdFc01i8wjGkUc22KidBMRxAm6hRrPHcxYvXJQ7z_oXXCZQLK5pgW1m_346YrJ0LQFPzZOzICFCMsngFmZoq_G3sjl4zH6jefD5FbY1B88uOv8hl4gz_B_tazNKu5uG9c5L4uG6pSFgHQ-4peRtlpt_Sow8v9nyKLLZGPapKOrOWRK9wEoQSJu1A_BuPFIjxX-7KZPi871ZFCbl4qecl4Ndw0dM3zUvPq9EXhZLE02Vs1lk1LcYOgZpLL-VHbYOCsyqLqjU5GLHl_i1geqN882tKZQG2N49Fcl7KWypQnmcn2PSlcDHlUkaIYV6GhQ5B0Up2FopsRdBBKAbEnY6K4OltweDFaOGwt66V4-Pmt_RTWAzT4h10b88kcNYuYxaIdBbtg8ak8qDcdxCqMLlrK3rxparnymcMPObbFeClppvLX3M3HgjTyhOUzIfzCZJbyeic8

That translates to http://www.isfdb.org/cgi-bin/pl.cgi?724848= somehow (note the equal sign at the end). ···日本穣 · 投稿 · Talk to Nihonjoe 13:50, 25 July 2019 (EDT)
It translates to

http://www.isfdb.org/cgi-bin/ea.cgi?134396&fbclid=IwAR3OXAEyuHT1_DnUzX-Tcv034vhq_SK67RFSzaq9YPKJ-Rn0XK4sDu_e1no

for me btw - which is not even the same author ID. And it is consistent with any link like that from Facebook since we started having this problem awhile back (after they changed how their links work). Are you sure you copied the correct link? 14:35, 25 July 2019 (EDT) —The preceding unsigned comment was added by Anniemod (talk • contribs) .
Depends if you are signed into Facebook or not. If you are signed into Facebook, it resolves to Nihonjoe's link. If you are not, it resolves to Anniemod's. -- JLaTondre (talk) 17:11, 25 July 2019 (EDT)
I see the same regardless if I am signed in (Firefox, I can see my name and so on) or not (Clean Chrome browser where I had never logged in). It may have something to do with having access to the link or not... Annie 17:14, 25 July 2019 (EDT)
I don't know about access. I just clicked the link above. Regardless, it is clear Facebook adds different parameters under different conditions when you click the "Follow Link" button. And ISFDB resolves those different parameters differently (no surprise). In an ideal ideal world, Facebook wouldn't add parameters to the URL, but that won't change. In an ideal world, ISFDB would handle extra parameters correctly (i.e. ignore them). I remember there was discussion about software issues with that. Guess the question is do we think the benefit (possible more exposure, new users) is worth the effort. I don't have an opinion on that - especially since it is Ahasuerus' time, not mine ;-). -- JLaTondre (talk) 17:48, 25 July 2019 (EDT)
That's right, we would have to change the way ALL ISFDB Web pages process and validate parameters. It should be doable and would also result in certain additional benefits. Unfortunately, it would be time-consuming :-( Ahasuerus 20:14, 25 July 2019 (EDT)
is the site behind an apache proxy or equivalent? Seems like something that could be done at that level, by not passing that parameter to the processor at all. --Unapersson 13:05, 22 August 2019 (EDT)
That's a good point. It may be possible to configure the Web server to pre-parse and modify incoming requests, stripping Facebook-added parameters. The downside is that it would also mean making configuring an ISFDB server more difficult and restrictive. Food for thought... Ahasuerus 12:57, 23 August 2019 (EDT)
This is exactly the type of reason why it would be very good to reduce the number of entry points in our code. By this I mean ideally it would be nice to have a very few CGI files (one would be great) and have that parse the path and query string after that (loading Python libraries as needed, etc.). That sort of transition would allow for greater flexibility (it might be possible to deploy without CGI, e.g., WSGI, etc.) and security (moving all the Python libraries out of the web browsers executable/CGI path and instead into Python packages and modules, etc.). Uzume 18:59, 18 September 2019 (EDT)
Sorry, I gave two different URLS. The example "native Facebook" link is for a different one than the other. I mixed up two different ones, somehow. :) ···日本穣 · 投稿 · Talk to Nihonjoe 18:55, 25 July 2019 (EDT)
Lol I didn't even notice the author ids were different (despite Annie saying that). I focused on the parameter differences. -- JLaTondre (talk) 19:25, 25 July 2019 (EDT)

"Translations without Notes" - Reorganizing the report

Here are the numbers behind Translations without Notes: 

+--------------------+--------------------+
| English            |               6476 |
| Italian            |               6386 |
| French             |               4907 |
| German             |               4227 |
| Dutch              |               2554 |
| Portuguese         |               1108 |
| Spanish            |                774 |
| Polish             |                255 |
| Finnish            |                233 |
| Romanian           |                207 |
| Serbian            |                178 |
| Swedish            |                115 |
| Croatian           |                114 |
| Hungarian          |                112 |
| Danish             |                 68 |
| Turkish            |                 45 |
| Czech              |                 44 |
| Lithuanian         |                 44 |
| Japanese           |                 41 |
| Slovenian          |                 20 |
| Slovak             |                  8 |
| Esperanto          |                  8 |
| Chinese            |                  6 |
| Norwegian (Bokmal) |                  5 |
| Galician           |                  5 |
| Korean             |                  4 |
| Norwegian          |                  4 |
| Latin              |                  4 |
| Scots              |                  3 |
| Middle English     |                  2 |
| Catalan            |                  2 |
| Estonian           |                  2 |
| Russian            |                  2 |
| Hebrew             |                  1 |
| Albanian           |                  1 |
| Mirandese          |                  1 |
| Scottish Gaelic    |                  1 |
| Thai               |                  1 |
| Malay              |                  1 |
| Old English        |                  1 |
| Icelandic          |                  1 |
+--------------------+--------------------+

Based on editor feedback, my tentative plan is to create separate cleanup reports for English, Italian, French, German, Dutch, Portuguese, Spanish and Japanese translations. The first 7 have more than 500 affected translations while Japanese is the 7th most common language in the database and sees a lot of turnover.

The remaining languages will continue to be covered by the existing cleanup report whose name will be tweaked. We can also split it into language-specific tables and have a "table of contents" at the top of the page to make it easy to jump to the language of your choice.

Does this sound like a good idea? Anything else that we need to change or tweak while we are at it? Ahasuerus 15:52, 25 July 2019 (EDT)

How did Portuguese sneak up that high on the list... :) I like the plan - it will make that project a bit more manageable. I am not sure that we need the Japanese on its own - they always show up close to the top of the generic report anyway - but if it is not that hard to split it, I guess we might as well. Annie 16:30, 25 July 2019 (EDT)
I like this idea. Looks like I need to work hard to bring the number of Japanese titles even higher. Maybe I can get it to the top five. :) ···日本穣 · 投稿 · Talk to Nihonjoe 16:34, 25 July 2019 (EDT)
How hard it will be to add the parent's title or language (or both) in the report alongside the title (similarly to how advanced search shows titles for example)? It is not critical but sometimes it is helpful to work per language pair (mainly because the names of the translators become familiar and I usually have their pages open on the side...) Annie 21:04, 25 July 2019 (EDT)
It should be eminently doable. Ahasuerus 21:53, 25 July 2019 (EDT)

(unindent) OK, it's decided then. I have another 550 Fixer-harvested ISBNs to process and then I will work on this FR. Ahasuerus 15:42, 31 July 2019 (EDT)

The Shaver Mystery Compendiums - Call for Volunteers

6 Shaver Mystery Compendiums have been added by Fixer. Looking for a volunteer willing to add Contents-level items. (July and August are Fixer's busiest months because September is typically the busiest month in the publishing world.) Ahasuerus 17:45, 28 July 2019 (EDT)

I will add them later today - will see if I can figure out if all of the art items from the magazines were reprinted or just some of them. Annie 13:35, 29 July 2019 (EDT)
Fiction imported; will work on covers, ebooks and so on and a second check if we need any variants instead of the main titles later today. Annie 14:14, 29 July 2019 (EDT)
Thanks! Ahasuerus 15:10, 29 July 2019 (EDT)

Collected Short Stories (H. P. Lovecraft)

I am planning to convert this to a publication series - it looks weird with all the variants and so on - and it will allow us to actually mark the correct editions as part of the series. Anyone can see a reason not to? Annie 14:45, 29 July 2019 (EDT)

Never mind, they already have a pub series. Still something does not feel right... Annie 21:00, 31 July 2019 (EDT)
It appears that they should be in two publication series: Tales of Mystery & the Supernatural and "Collected Short Stories", which we don't support. I do think that the use of a title series which really only applies to the Wordsworth printings here is not appropriate. I would suggest removing the title series and putting these in a new publication series with a notes on both pub series records explaining a parent child relationship. This would be workable unless Wordsworth reprints these as part of Collected Works but not as part of Tales. However, I suspect that it unlikely. --Ron ~ RtraceTalk 06:52, 1 August 2019 (EDT)

What to do with pubs that are not spec-fic?

Hi. I wanted to check with the community what the feeling is about submitting deletions of pub records for which no evidence can be found they are spec-fic, and for which the author is not above the 'threshold' (yeah, I know, quite vague... :)?
I am well aware that it's not fun for the editor(s) that have put all the work in to get their work erased (I wouldn't like it myself). But if we let these records stay because someone happened to have put a lot of work in it, where will it end? It becomes trickier if a verified pub record turns out to be not spec-fic. I tend to leave these alone but these too should - strictly speaking - be deleted from the database (after contacting/notifying the PV first). Thought? Suggestions? MagicUnk 08:05, 31 July 2019 (EDT)

Well, we do not want chemistry and language textbooks (yep, we had some :) ). Can you share a few links of books you consider deleting? Annie 12:40, 31 July 2019 (EDT)
Yup, much easier to make a determination if we know which book(s) you are considering. ···日本穣 · 投稿 · Talk to Nihonjoe 18:02, 31 July 2019 (EDT)
Here are a couple of examples:
Out of the Dark (even though it's primary verified - this one's borderline, perhaps?)
Born of the Sun (even though it's recorded in Locus1 - unjustified imo)
The Bailey Game (did ask ClarkMCI, no feedback to date)
The Raging Quiet (here ClarkMCI made a note that he has suspicions this is not spec-fic)
I checked Goodreads reviews, and not really one that I could find that convinced me these contained spec-fic elements warranting inclusion. MagicUnk 07:51, 2 August 2019 (EDT)
All of these novels are by established SF authors, so I would flip the "non-genre" flag and document what we know about them in notes. It's been my experience that it's more beneficial to keep borderline cases in the database and explain why they are "borderline SF" or "not really SF even though they may look like SF" in Notes. Not only does it help our users, but it also prevents robots and new editors from creating "genre" records in the future. Ahasuerus 10:50, 2 August 2019 (EDT)
Hmm, that's something we could do of course. But then we are ignoring the 'authors above a threshold' rule (assuming they are non-genre), don't we? Afaik the authors of the examples above aren't really above the threshold - even though they are established SF authors. We can update/remove that rule of course... What are the other editors' practices related to non-genre publications? MagicUnk 10:59, 2 August 2019 (EDT)
Are we? The idea of the threshold rule is not to count someone’s work as if they are tomatoes and go by percentages but to allow us not to burden the DB with the collected works of a prolific author just because they happened to write 1 genre novel. If the author is considered a genre one, they are above the threshold IMO. There is a reason why that rule does not say anything about exact numbers. Annie 11:25, 2 August 2019 (EDT)
PS: And borderline spec fic belongs here for two reasons: the boundary will always be in the eye of the reader and so that we do not need to make all the explanations of why it is not. And especially for those borderline ones, I really do not feel like we should be removing them based on GR reviews alone (if you look at The Amazing Mycroft Mysteries and their reviews, you would decide that they are not genre either. And yet, as I read the first two lately, I can tell you that they belong (the first one has killer-bees and enough science around them to qualify it at least as a border case, the second one has a working medium). I would opt on the inclusion side unless either someone reads the book and can make a decision or at we find another way to make sure they are not speculative at all. Or that the author is not a predominantly genre one - if they are, then the works are in anyway. Annie 12:50, 2 August 2019 (EDT)
As to the threshold rule. The relevant parts of the policy say Works (both fiction and non-fiction) which are not related to speculative fiction, but were produced by authors who have otherwise published works either of or about speculative fiction over a certain threshold [are included], and, Works that are not related to speculative fiction by authors who have not published works either of or about speculative fiction over a certain threshold. [are excluded]. Mirriam-Webster has Threshold: a level, point, or value above which something is true or will take place and below which it is not or will not. For me, this means that the policy says that even for established SF authors who have not produced 'much' (ie are below the threshold), the non-spec-fic should not be entered. Cursory reading of the threshold-related discussions over the years seem to support this interpretation. Now, we may not want the policy to mean 'above a certain value', but then I would like to see the rules of acquisition rephrased to somehow include 'non-spec-fic work of established SF authors' (whatever established really means :-))
Now, having said that, there's - as you rightly point out - the other side of the medal; when is a work borderline SF, and thus eligible for inclusion? I concur that it is difficult to figure out without having read the book whether they have to stay or not from reviews and synopses alone. So, concluding, and erring on the side of caution, I surmise the current consensus is to leave them in when there's not unambiguous proof of the contrary, but add a note as to the debatable SF contents of the work. If it can be unambiguously established the contents is non-spec-fic, and the author is below the threshold (even when an established SF author), it has to go out. In practice, the latter case may not happen at all - unless someone actually reads the work, right? MagicUnk 16:31, 2 August 2019 (EDT)
How do you define the threshold? Not what the dictionary says, how do you understand it in ISFDB? We read that rule somewhat differently I think - mainly on how threshold is defined. It sounds like you are trying to find a numeric representation of that value. What I am reading when I see that is exactly what you want to rewrite it as - an author over the threshold is not just about the numbers, it is about "is that one of our authors?". I just cannot see a difference between what we have and what you are proposing to change in the wording. Some authors are ours under one pseudonym (Nora Roberts and her Robb pseudonym for example), some are ours under all names. Annie 16:59, 2 August 2019 (EDT)

[unindent] Wellll... I think that's the issue - we're not interpreting the current rules exactly the same way, which is a Bad Thing™. If I may paraphrase; you and Ahasuerus seem to imply that whenever the author is an SF author -ALL- publications should be recorded. This implies - amongst other things - that however small their output may be, all publications have to be recorded irrespective, as long as they are a recognized SF author. Whereas I'm interpreting the rules as "even if the author is an established/recognized SF writer, if his/her SF output is 'low', everything that's non-SF should -NOT- be recorded". Do note that new editors do not have all the ISFDB history, so are likely to go and check the Mirriam-Webster definition of threshold, and will end up with interpreting it as a numerical threshold - as I did. Going back to the examples given above, authors such as Gillian Cross, Welwyn Wilton Katz, and Sherryl Jordan, notwithstanding having produced SF works, can hardly be considered established SF authors imo. Now, I'm not having a preference one way or the other 'per se', but the rules should be as unambigous as we can make them, especially so because we do not want new editors to interpret the rules - nor the moderators for that matter. So, either we have

  1. If it's a 'recognized' SF author, record ALL (ie SF -and- non-SF) his/her works, or
  2. If it's an author with SF works above a certain threshold (numerical), record ALL his/her works (and consequently, if the output is 'low', do NOT record all of his/her non-SF works)

I've been interpreting the rule as the latter (and I suspect many other editors & moderators with me - chime in and tell me if I'm wrong here ;). So, do we want to organize a poll as to clarify if it's 1, or 2 we want? If we want 1. we need to rephrase the rules, as it's confusing right now for new (non-English-speaking) editors (which I am), as they are likely to interpret it as 2. Also, if we would go with 1., the danger exists we end up with loads and loads of non-spec-fic works of 'established' SF authors, however low their output is/has been.

---And yes, I am well aware of the difficulty of coming up with acceptable definitions of 'recognized SF author', or, 'author with SF works above a threshold' - but that's food for another discussion...

Also, we should be careful not to muddy the waters by introducing the notion of 'borderline' SF, as these need their own set of rules, of which the most important one is (I think): if in doubt, you are allowed to add it to the DB, but make sure to add a clear note about its dubious SF contents. Regards, MagicUnk 11:49, 4 August 2019 (EDT)

Early on, we had multiple discussions about the "threshold". Lots of different definitions were proposed, including numerical ones like "at least 50% [75% etc] of the author's output is SF". We always ended up with exceptions and exceptions to exceptions, so we were never able to come up with an explicit rule. The best we could do was to state that:
  • ... "certain threshold" is hard to define, but we need to draw the line in a way that would exclude Winston Churchill, who published at least one work of borderline speculative fiction. The goal here is to avoid cataloging everything ever published by James Fenimore Cooper, Robert Louis Stevenson, Honoré de Balzac and other popular authors. Instead, we want to catalog their speculative fiction works only.
Note that it doesn't say anything about the author being "recognized". For example, take George Orwell. By any measure -- sales, critical recognition, public awareness, etc -- he is one of the most recognized authors of speculative fiction. Yet we do not list his non-speculative novels.
For what it's worth, here is how I usually approach the issue when deciding whether to include non-genre works for an author. I ask myself: "If an average reader comes across an unfamiliar work by this writer, will she suspect that it is SF?" In the cases listed above, the answer is "no", so their non-SF doesn't get included. If the answer is "yes" or "probably", I include the non-SF works.
A few other things to keep in mind. There was a time when the only non-genre works supported by the software were NOVELs. It made life difficult and sometimes editors used "creative" solutions. They had to be revisited once the software was able to handle all types of non-genre titles. Some of these "creative solutions" may still be lingering in dark corners.
Also, at one point the policy was to enter non-genre works if they had been reviewed in genre-publications. The policy was changed years ago, but, yet again, some ineligible non-genre works still exist in the database. Ahasuerus 11:02, 5 August 2019 (EDT)

Japan Fantasy Novel Award

Can we add this one? It was given from 1989-2103, and then started up again in 2017. It has the following categories:

  • Japan Fantasy Novel Award
    • Grand Prize
    • Award of Excellence
    • Nomination

I will add them once the award is created. Thanks! ···日本穣 · 投稿 · Talk to Nihonjoe 15:50, 6 August 2019 (EDT)

Done. As per this discussion of the Clarke Award, "Grand Prize" and "Award of Excellence" are not separate categories in the ISFDB world but rather different award levels within the same category. The category has been created and I have added a note about the first and the second places being called "Grand Prize" and "Award of Excellence" respectively. Ahasuerus 17:08, 6 August 2019 (EDT)
Based on your comparison to the Clarke Award, there should be two categories under win:
Win:
  • Grand Prize
  • Award of Excellence
Neither of these should have a "poll place" because you either win the Grand Prize or Award of Excellence or you don't. There is no ranking beyond winning one of those two or not. All of the nominees are eligible for both. The prize committee can choose to award in any given year either of those to one or more nominee (two is the most in a given year for either, at least historically), or choose to award only one of them to one or more nominees. The remaining nominees are just nominees for the Japan Fantasy Novel Award in general. I hope that makes sense. ···日本穣 · 投稿 · Talk to Nihonjoe 18:50, 6 August 2019 (EDT)
Originally, the Clarke Award was set up to have separate categories for winners, runner-ups, and shortlisted works. However, based on the outcome of the linked discussion, we changed it to have a single "Best Science Fiction Novel" category. Clarke winners are now entered as "Award Level 1", runner-ups as "Award Level 2" and other nominees as "Finalists" (a supported "special award level".)
If my understanding is correct, "Japan Fantasy Novel Award" has a similar hierarchy: "Grand Prize" is effectively "Award Level 1", "Award of Excellence" is "Award Level 2" and the rest of the nominees are "Finalists". Is this a reasonable approximation of the way the award works? Ahasuerus 19:49, 6 August 2019 (EDT)
Kind of. The problem is that both "award levels" are not awarded every year, as opposed to the Clarke Award where they are. If you win a Japan Fantasy Novel Award, you are awarded either the Grand Prize or the Award of Excellence. ···日本穣 · 投稿 · Talk to Nihonjoe 20:53, 6 August 2019 (EDT)
Let me double check that I understand correctly. "The Grand Prize" is a higher award level than "The Award of Excellence", right? And their recipients are selected from the same pool of books? Ahasuerus 10:22, 7 August 2019 (EDT)
It's always listed higher on websites that list awards, so probably? The recipients of both are from the same pool of nominees. ···日本穣 · 投稿 · Talk to Nihonjoe 12:53, 7 August 2019 (EDT)
There are some years where a Grand Prize is not awarded, so considering it "Award Level 1" seems weird in years where only the Award of Excellence was given. ···日本穣 · 投稿 · Talk to Nihonjoe 20:53, 6 August 2019 (EDT)
Well, similar things have been known to happen. For example, consider the 1976 and the 1994 John W. Campbell Memorial Awards, which had no winners and two (ranked) finalists. Or the 2015 Hugo awards, when "No Award" won in the "Best Novella" and the "Best Short Story" categories. Ahasuerus 10:22, 7 August 2019 (EDT)
I guess I'm most concerned about how it will show up on the title and author pages. As long as it shows "Grand Prize" and "Award of Excellence", then it should be fine. ···日本穣 · 投稿 · Talk to Nihonjoe 12:53, 7 August 2019 (EDT)
Maybe this is a feature request: to have the option of assigning names to the "places" for an award, or to just use numbers. That way, it displays "Grand Prize" instead of "1". I know this wouldn't be applicable in all cases, but it seems this (and perhaps the Clarke Award and other) are a bit of a hybrid between awards like the Hugo (which have multiple categories) and single awards with "poll places" (or rankings) since they give a name to the places, but share a common nomination pool. ···日本穣 · 投稿 · Talk to Nihonjoe 13:13, 7 August 2019 (EDT)
Well... The good news is that we already have a related FR, FR 656, Add a "Term used to described runner-ups" field to Award Category. The bad news is that it would be a fairly time-consuming change. Nothing too drastic, just a bunch of man-hours. Ahasuerus 15:49, 7 August 2019 (EDT)
Another wrench for the works: in 2005, a person who would have won the Award of Excellence declined it. There's not currently a way to indicate that since you can't select both "Poll place" (to indicate they would have won place 2, the Award of Excellence) and "Special" (to indicate they declined the award). ···日本穣 · 投稿 · Talk to Nihonjoe 13:44, 7 August 2019 (EDT)
That's right. The only way to capture both the fact that s/he was supposed be given the Award of Excellence and that s/he subsequently decline it would be to have a separate category for the Award of Excellence and, presumably, another one for the "Grand Prize". I guess we could do that, but where would the nominees/runner-ups go then? Ahasuerus 15:52, 7 August 2019 (EDT)
That's the big question, isn't it? This one really is a hybrid. ···日本穣 · 投稿 · Talk to Nihonjoe 17:23, 7 August 2019 (EDT)
A third category "Award Nominees"? When someone wins, they get removed and moved to the proper award (and we add notes on the three categories explaining the situation). Why won't that work? Annie 17:30, 7 August 2019 (EDT)
Well, it would work, but then we would have the same problem that we had with the Clarke Award prior to the changes. Having nominees in one category, Grand Prize winners in another category and Award of Excellence winners in yet another category would mean that the data for one award year would be scattered across multiple categories. It wouldn't be an accurate model of the way the award data is structured, so third party developers who use our award data would need to add an exception and so on.
Given our software limitations, I guess we need to decide whether it's more important to display the words "Grand Prize" and "Award of Excellence" on award pages or to have all nominated works listed within the same category (and use to document "Grand Prize" and "Award of Excellence".) Ahasuerus 08:15, 8 August 2019 (EDT)
I am less concerned about the award pages (we can add notes there) and more concerned on how things look on title pages -- we cannot add notes explaining what is what there. I know that we have challenges with the model (because it as built based on how US awards look like :) ) - but then we do have two types of consumers of the data - the people that look at the site and the people that use the DB itself. Just thinking aloud. Annie 12:16, 8 August 2019 (EDT)

(unindent) I guess we might as well do it right and change the software to support "Displayed Award Level". I assume that:

  • The new optional "Displayed Award Level" field will be at the award level, not at the award category level. This will support scenarios where the displayed award level changes from year to year.
  • The new "Displayed Award Level" field will be in addition to the currently existing "Award Level" field. The latter will continue to be used for sorting purposes.
  • The new "Displayed Award Level" field will allow arbitrary text like "Grand Prize" and "Award of Excellence" to be entered.
  • If no "Displayed Award Level" value is entered for an award, the value of the "Award Level" field will be displayed.

Does this look about right? Ahasuerus 09:55, 11 August 2019 (EDT)

I think so. Annie? ···日本穣 · 投稿 · Talk to Nihonjoe 16:20, 11 August 2019 (EDT)
Looks good. Do we want to have the award name always in English or do we want to allow a “Native / English” format as well? If the latter, we will also need the transliterations fields. As these names will show up on title pages, I’m inclined towards allowing the double name - especially because some of this names may not have an agreed upon English name and whatever is chosen will be the editors’ interpretation. Annie 02:52, 12 August 2019 (EDT)
At this time none of the award-related records, i.e. award types and award categories, support transliterated values. If we decide to add support for them, we should probably do it across the board. Ahasuerus 11:35, 12 August 2019 (EDT)
True. Which is why I brought it up. Because this one needs transliteration in its main form as well. Annie 12:34, 12 August 2019 (EDT)
I like the idea of adding transliteration fields for the awards. ···日本穣 · 投稿 · Talk to Nihonjoe 14:21, 12 August 2019 (EDT)

(unindent) OK, FR 1295 "Allow entering transliterated values for awards-related values" has been created. Also, FR 656 has been changed to reflect the "Displayed Award Level" functionality discussed above. Ahasuerus 13:59, 15 August 2019 (EDT)

Okay, this award has been entered through 2018. The 2019 winners have not yet been announced. ···日本穣 · 投稿 · Talk to Nihonjoe 19:50, 24 October 2019 (EDT)
Great, thanks! Ahasuerus 19:57, 24 October 2019 (EDT)

Chen Jiatong

Would anyone happen to know the Chinese spelling of Chen Jiatong's name? I have found a bunch of English-language articles about him, including a recently added SFE3 article, but I don't know how his name is spelled in Chinese. Ahasuerus 17:01, 9 August 2019 (EDT)

Looks like it's 陈佳同 per this book. ···日本穣 · 投稿 · Talk to Nihonjoe 18:12, 9 August 2019 (EDT)
The National Library of Singapore agrees. Thanks! Ahasuerus 10:12, 11 August 2019 (EDT)
No problem. ···日本穣 · 投稿 · Talk to Nihonjoe 16:19, 11 August 2019 (EDT)

Dublin Worldcon

If someone is attending and wants to meet, let me know :) That also means I will be (mostly) out of pocket on the site after today and until late next week. Annie 14:26, 12 August 2019 (EDT)

According to Template:Moderator-availability, Rtrace headed to Dublin a few days ago. Watch out for leprechauns! Ahasuerus 17:51, 12 August 2019 (EDT)
I need to remember to update that thing when I am off... Well, I was considering catching a few and bringing them back to help with Fixer's queues... :) But then they are not that reliable I guess. Annie 19:12, 12 August 2019 (EDT)
Indeed I am. I’ve sent an email with my contact info. I recall that we had problems with the wiki email function in the past, so let me know if you don’t get it. Hope to see you there. --Ron ~ RtraceTalk 04:58, 13 August 2019 (EDT)
Got it - see you in Dublin. :) Annie 10:34, 13 August 2019 (EDT)

Support for 3 new language codes added

The software has been updated to support the following new languages:

  • Guarani
  • Interlingua
  • "South American Indian language", which, as per the ISO 639-2 standard, covers all South American Indian languages

Ahasuerus 17:45, 12 August 2019 (EDT)

"Translations without Notes" split into language-specific cleanup reports

As per FR 1291, the cleanup report "Translations without Notes" has been split into multiple language-specific cleanup reports. The original report is now called "Translations without Notes - Less Common Languages". Additional columns ("Original Title", "Language") have been added throughout.

Updated data will become available when the nightly process runs in a few hours. If you run into any issues, please post your findings here. Ahasuerus 22:48, 13 August 2019 (EDT)

Awesome! ···日本穣 · 投稿 · Talk to Nihonjoe 13:38, 15 August 2019 (EDT)
Thanks! And I love the new format of the reports with the extra columns. Annie 17:19, 27 August 2019 (EDT)
Glad to hear the new reports are useful! Ahasuerus 20:42, 27 August 2019 (EDT)

Professor Bernice Summerfield

For the series: Professor Bernice Summerfield (http://www.isfdb.org/cgi-bin/pe.cgi?12512) the first 6 books have usually different names for the original and the identical reprint. This series pops up in my cover art verification as different titles have the same cover link. For none I found a verified pub, so I'd like to unify them by dropping the "Professor Bernice Summerfield and" and cleanup the duplicate records. Objections? --Stoecker 11:00, 15 August 2019 (EDT)

The titles should be as they appear in each book. If that makes them not "unified", then so be it. We shouldn't be changing them just to fit a sense of order. ···日本穣 · 投稿 · Talk to Nihonjoe 13:38, 15 August 2019 (EDT)
Please read what I wrote before answering! None of the entries have a verified status, so the data is only based on the externally visible data and thus there should be no difference with identical covers (and identical ISBN BTW). --Stoecker 15:52, 15 August 2019 (EDT)
I did read what you wrote. The couple that I checked have the full title as we list it on the cover. If we don't have a PV, and there is no Look Inside available, that's what we have to go with. When the titles have "Professor Bernice Summerfield and the..." as part of the title, it's obviously part of the actual title, unless we can get a PV to show it's otherwise listed on the title page. It's exactly the same as all the "Harry Potter and the..." titles. ···日本穣 · 投稿 · Talk to Nihonjoe 16:41, 15 August 2019 (EDT)
OK. In this case I can change all the titles and covers by adding "Professor Bernice Summerfield and" to the titles without? --Stoecker 17:42, 15 August 2019 (EDT)
If that's what's on the covers, then yes. Lacking any PV to check with, we have to go by what's on the cover or Look Inside. If the cover doesn't have that as part of the title, then we shouldn't be adding it. ···日本穣 · 投稿 · Talk to Nihonjoe 18:29, 15 August 2019 (EDT)
So, for example, this one doesn't have the "and the" as part of the title, so the "Professor Bernice Summerfield" is just the name of the series. On the other hand, this one has "Professor Bernice Summerfield and the Dead Men Diaries " on the cover, so that's what we use for the title unless a PV or Look Inside shows differently. ···日本穣 · 投稿 · Talk to Nihonjoe 18:32, 15 August 2019 (EDT)
I only refer to 1-6. It seems since 7 the "and" is missing. That's why my first proposal was to also drop that for 1-6. But as you rejected that I'll unify 1-6 with the "and". If later a PV notes that this is wrong it at least will be much easier to correct it by simply editing the title records. --Stoecker 08:02, 16 August 2019 (EDT)

Imadjinn Awards

Here's a new award to consider adding. It has the following categories (those marked with * may or may not be genre for ISFDB):

  • Best Anthology *
  • Best Children's Book *
  • Best Historical Fiction (not genre)
  • Best Horror Novel
  • Best Fantasy Novel
  • Best Literary Fiction Novel *
  • Best Non-Fiction Book *
  • Best Paranormal Romance Novel
  • Best Romance Novel *
  • Best Science Fiction Novel
  • Best Short Story *
  • Best Short Story Collection (single author) *
  • Best Thirrler Novel *
  • Best Urban Fantasy Novel
  • Best Young Adult Novel *

Should we add them? ···日本穣 · 投稿 · Talk to Nihonjoe 14:28, 15 August 2019 (EDT)

The award is apparently given by a regional (Kentucky) convention which has been active for the last 6 years. It seems similar to Endeavour Award, which we support, so it appears to be eligible. Ahasuerus 14:35, 15 August 2019 (EDT)
Done. Ahasuerus 08:20, 25 August 2019 (EDT)
Thanks! I'll work on them when I get done with the Japan Fantasy Novel Award (only about 10 more years to enter). ···日本穣 · 投稿 · Talk to Nihonjoe 20:00, 27 August 2019 (EDT)

Spaces in Japanese names

Can we have a report that lists people with spaces in their names if they are Japanese? For example, "のの原 兎太" as opposed to "のの原兎太". The Canonical Name shouldn't have any spaces in it, but I haven't figured out how to do an advanced search that finds them. ···日本穣 · 投稿 · Talk to Nihonjoe 22:08, 22 August 2019 (EDT)

You can do "Canonical Name contains % %" plus "Working Language is exactly Japanese" to try to get at this. You might be able to reduce the list with a few more restrictions, but there is a bit of noise since you pick up the names that are in other languages. --MartyD 08:01, 23 August 2019 (EDT)
Right, that's exactly what I use to find errant spaces. Ahasuerus 12:51, 23 August 2019 (EDT)
Awesome. I've cleaned those up. ···日本穣 · 投稿 · Talk to Nihonjoe 19:24, 23 August 2019 (EDT)

Currency symbols and abbreviations

Do we have somewhere a reference list of currency symbols and abbreviations? Help:Screen:NewPub#Price contains several illustrations but no hyperlink to a more complete list at ISFDB.org, nor elsewhere.

E.g. France: For the currencies of France, we report prices "FR 6" (1865), "F50.00" (1947), and "4 F" (1966) --for publications of Voyages Extraordinaires #1 T7386 and Baltimore Gun Club #1 T7389. Wikipedia-EN implies a single franc (F or Fr or FF) from 1795 to 1960. --Pwendt|talk 13:01, 23 August 2019 (EDT)

This is the only list we have that I know of. The different French Francs are afaik grounded in the different restarts of the currency. It may be that Linguist knows more about the matter, and I'll post a link at his talk page. Christian Stonecreek 13:35, 23 August 2019 (EDT)
I just started Help:List of currency symbols, if anyone wants to add to it or correct it. ···日本穣 · 投稿 · Talk to Nihonjoe 20:46, 23 August 2019 (EDT)
We can also use this page for reference. ···日本穣 · 投稿 · Talk to Nihonjoe 20:49, 23 August 2019 (EDT)
As far as French francs are concerned, it seems to me that this database has mainly used "F" directly followed by the number, e.g. "F5.50", just like the dollar sign. At least, this was the standard rule Hauck and I followed. The difference in currencies does not really correspond to a difference in symbols, which vary greatly from publisher to publisher, as well as with publishing dates. Whenever I meet something like "FR 6" or "4 F", I change it to the standard F6.00 or F4.00. The only tricky cases are :
  • the period between 1945 and 1959, when the one franc piece corresponded to the lowest possible value (due to the dramatic post-war devaluation of the franc). I usually write prices indicated during that interval without any decimals, as these were just impossible. The only exception to this (unfortunately) comes form the lingering but rather rare use of the old 50 centimes piece until the end of the ’40s (mainly for newpapers and such).
  • the short period following 1960, when prices appeared in "new francs" usually noted as "NF" (one "new franc" equalling 100 "old francs"). But as this practice of noting NF disappeared with time, and there was nothing official in the NF notation, prices in new francs are just noted the standard way, with a commentary in the notes if necessary.
If no one objects, I'll add a line about French francs in the list, summing up our usual practice in the matter. Linguist 04:59, 24 August 2019 (EDT).
Which list? Help:List of currency symbols or Help:Screen:NewPub#Price? ···日本穣 · 投稿 · Talk to Nihonjoe 02:04, 25 August 2019 (EDT)
The latter (since the issue has been dealt with in the former). Linguist 04:08, 25 August 2019 (EDT).
Works for me. Feel free to add or correct anything on Help:List of currency symbols. ···日本穣 · 投稿 · Talk to Nihonjoe 13:28, 25 August 2019 (EDT)

So all non Latin characters are followed by numbers without a space character, but currencies in Latin characters use a space before the number. What I don't understand is: why doesn't the French F follow this rule as the only Latin currency.
And I miss the Swedish krona SEK in Help:Screen:NewPub#Price --Zapp 06:33, 26 August 2019 (EDT)

Summary of ISFDB Publications search > Price contains: fr --two characters
'Bfr ' -- the usual hit, these four characters uniformly
Sfr Sfr. sfr sfr. -- four different strings, always followed by a space (narrow SEARCH)
Fr Fr. FR -- three different strings, followed by a space
Fr.-- no space
The use of 'FR ' that I mentioned above happens to be unique, and also the only hit for this search prior to year 1900. --Pwendt|talk 11:22, 26 August 2019 (EDT)
Our database Advanced search evidently strips leading as well as trailing spaces. Search '9 f' will find some uses of closing currency symbol F.
Summary of ISFDB Publications search > Price contains: 9 f --three characters (SEARCH)
F FF Ft --three different strings, all at end of price.
Wikipedia evidently uses trailing currency symbols for denominations of notes and coins; thus, 20F price may be paid by two 10 F coins. --Pwendt|talk 12:02, 26 August 2019 (EDT)

Tauchnitz Edition format

Do we know that the Tauchnitz Collection of British Authors was published sometimes in hc or tp format, as our publication records report?

I infer pb format from the digital copy of #3440 that I viewed at HathiTrust yesterday. (Augmentation of the publication record P567383 is in progress and I will add a publication series Note, too.)

First, I look for confirmation or correction of my interpretation that HDL images 6-7 and images 288-89 of 299 show the original front outside/inside cover and back inside/outside cover, or page 1 to "page 4 of cover" in Tauchnitz terms. Meanwhile images 1-5 and 290-99 show --perhaps with buffer images-- the materials, including hard covers, in which the original was bound by Cornell University Library or donor Theodore Stanton (image 3, with terms of holding and circulation). Right?

Thus I infer paper covers. HathiTrust reports size 16cm, which implies pb format --if not digest or another paper format, but all our publication records for the series reports hc, tp, or pb.

The August 1900 list of Latest Volumes ends (page 4 of cover) with this statement now quoted in the publication record, and destined for the series Note:

"The Tauchnitz Edition is to be had of all Booksellers and Railway Libraries on the Continent, price M 1,60. or 2 francs per volume. A complete Catalogue of the Tauchnitz Edition is attached to this work."

From this I infer a single format, rather than multiple formats, as of August 1900.
(Because Tauchnitz is based in German, I entered price "ℳ 1.60".) --Pwendt|talk 13:44, 23 August 2019 (EDT)

Since paperbound and hardcover formats are verified it seems reasonable to assume that the titles were published - likely simultaneously - in both variants, at least for some time. This was the standard procedure for some German publishers at the beginning of the 20th Century. Stonecreek 01:45, 24 August 2019 (EDT)

Neffy Awards

Should we add the Neffy Awards (or "National Fantasy Fan Federation Speculative Fiction Awards")? According to this page, they have been awarded annually since 2005, and periodically since 1949. I haven't found a list of the older awards yet, but I'll keep looking. The 2019 list is here, and the 2018 list is here. Locus seems to report on them. ···日本穣 · 投稿 · Talk to Nihonjoe 02:13, 25 August 2019 (EDT)

I could have sworn that we discussed adding this award a few years ago, but I can't find anything in the archives. Perhaps it was a similarly named award?
In any event, checking the award history, it looks like it's mostly a media award. However, it also includes enough fiction categories to make it arguably worth adding.
As an aside, their naming conventions can be confusing. For example, in 2010 their "Best SF/F Author" award was given to "Suzanne Collins – Mockingjay". I assume it means that it was actually a "Best SF/F Fiction" category rather than a "Best SF/F Author" category. Oh well, nothing that we can't work our way around. Ahasuerus 14:03, 27 August 2019 (EDT)
OK, a new award type has been created. I'll leave category creation to the folks who will be working on this award. They change from year to year and can get rather convoluted. Ahasuerus 19:42, 9 September 2019 (EDT)

Maithili added

The software has been updated to support the Maithili language. Ahasuerus 16:17, 27 August 2019 (EDT)

Authors with Author Data and One Non-Latin Title

Can we make entries ignorable on this report? There are a number where they just need to be ignored. ···日本穣 · 投稿 · Talk to Nihonjoe 19:32, 29 August 2019 (EDT)

I support this request :) Annie 19:36, 29 August 2019 (EDT)
Especially since a large number of the names in the list are alternate names that are already correctly varianted to the canonical name. ···日本穣 · 投稿 · Talk to Nihonjoe 19:48, 29 August 2019 (EDT)
It would be easy to do, but the fact that it's explicitly designed to find authors with one non-Latin title makes me wonder. Anyone recall the original reasoning behind this cleanup report? Was it, by chance, one of those reports which were created to go after the "low hanging fruit"? Is it still relevant now that we have cleaned up a lot of language issues? Ahasuerus 21:51, 29 August 2019 (EDT)
I do not think that it is relevant or needed anymore - it was part of the reports that were built around the time we were assigning languages to titles and dealing with the non-Latin author names. There is nothing there that we do not get from other reports for the ones where we need to do some work on. If you would rather kill it instead of allowing the ignore, I am all for it. Annie 22:20, 29 August 2019 (EDT)
If there are no objections, I will zap this report in a couple of days. Ahasuerus 12:52, 31 August 2019 (EDT)

Verification of electronic copies

Does a scanned edition of a book count towards verification? Would Transient be used if viewed anpreed Permanent if a copy is possessed? To what extent would the associated catalogue information (assuming a library-like source) be acceptable for completing fields? There are templates for a few sources (e.g. British Library, Gallica), but should there be a more standard approach (template, wording, format) to documenting the reference / link? Bear in mind that some sources require membership or presence at a physical site for viewing. Doug H 08:28, 30 August 2019 (EDT)

National libraries are not only acceptable, but wishable, I'd say (more than a vendor like amazon). They have the same goal in cataloguing the correct data (their main aim isn't to sell), and I use them whereever I can lay my hands on them.
Using a scanned copy (instead of a physical one) should imho always be used for transient verifications. Christian Stonecreek 10:49, 30 August 2019 (EDT)
A number of sites (e.g. Gallica, Hathi) support 3 levels - searchable (tells you number of hits, but shows no text), viewable and downloadable. Is there a distinction between viewed and downloaded (as in "I've seen" vs. "I have") for an electronic copy? Or would they both be lumped in as Transient? A scan isn't really the book, so is it more of a secondary source? Would it make sense to include "Scanned Copy" along with Blieler and Locus? Templates allow me to reference some of the sites / copies directly (e.g. Gallica), but I have made use of some downloads from my university library that gives me access to collections not publicly available. Would a template to incorporate the name/link be a better approach than simply using notes? Doug H 15:17, 30 August 2019 (EDT)
I would still argue that "I have/own a scan of the book in e-format" is different from "I own the book". You can "permanent verify" an e-book you have that is published as an e-book; I book that is marked as HC can be "permanent verified" only from a HC copy. Even if you see the whole book in a scan. So in your case I would Transient and add a note that the Transient is from a downloaded copy that I have. Annie 15:25, 30 August 2019 (EDT)
I would prefer a verification category intermediate to Primary and Secondary --regardless whether images of original covers and endpapers (and more?) are contained or absent; the latter because a re-bound or damaged book has been scanned, or because the scan is incomplete.
And I do prefer, in each publication record with digital copy as source, we specify whether it contains original cover or not (if appropriate: "apparently", "probably", with description, etc).
As yet I have written or updated hundreds of publication records noting some data from online copies, usually at HathiTrust, and I have not formally Verified any of them. My boilerplate, modified to fit the occasion:
* HathiTrust Digital Library provides full view of four copies including one with original cover: [that one is the one linked somewhere below, a hopeful unstated convention]
HDL holdings rarely include spine scans, a lack that I rarely note.
--Pwendt|talk 16:28, 30 August 2019 (EDT)
Annie, I agree they are different. But permanent vs. transient is temporal - do you still have or no longer have access to the "book". Saying a scan you have possession of is transient seems wrong. I'd prefer pure notes to such an approach. The permanent vs. transient seems to apply just as well to the scanned copy. Which is why I wondered if "Scanned Copy" is a valid secondary source - not the real thing but a good substitute? That approach offers only a Yes/No verification though. So a category between Primary and Secondary sounds nice, but probably mucks around too deep in the code to be easily implemented. If such an approach is viewed as 'good' and 'likely', it there a way to 'tag'/'template' entries to minimize the effort of conversion in the future? Pwendt's boilerplate works for him, but a more standardized approach based on some discussion would be better. So I'm hoping this generates some of that discussion. Doug H 16:58, 30 August 2019 (EDT)
That is why I said "I would argue" :) I do not verify based on scans (not because I would not but because I have other stuff to do before that) so I just offered an opinion on what I would do. :) If we agree on a different approach, I am ok with it. I also know that the fact that I have a scan today does not mean I won't misplace it tomorrow (with books at least it won't end up in a disk I throw away by mistake). Neither fits but my gut feeling is that if I had not seen the book in the format it is published, it is not a Primary Permanent for me.
These days more and more books get digitized so maybe we need a "Primary/scanned" type of verification (as Pwendt kinda proposed as well now reading up) ... And “Monitor/Notify” while we are at that (I enter book on behalf of a user who does not speak English, being able to mark it as such will mean that I will get the "changed" AND people know that they can ask me questions about the book because I show as active while the actual PV is around only when I call him to check and verify.
Back to the scans - if enough people think it should be Permanent, I will be fine. You may want to ping Ron (Rtrace) - he has quite a lot of books verified based on scans. Annie 20:01, 30 August 2019 (EDT)

See this archived discussion for a prior discussion that had some implementation ideas on this topic. -- JLaTondre (talk) 08:16, 1 September 2019 (EDT)

Based on that discussion and this, I'd be good with an additional "Scanned copy" form of Secondary Verification. It's pretty generic and non-linking (there may be a FR to deal with that). How would we document the additional information in the Notes? I like using templates, it ensures a standard approach, simplifies searches and stats gathering and enables future enhancement. We only catalogue one publication of a book regardless of the number of copies, so theoretically would need only one verification / scan reference for a given publication. However, scans vary in quality, completeness and other factors, so I wonder if there needs to be allowance for more than one. And different publication sites (Hathi, Google Books, ...) may or may not be showing the same copy, but generally indicate the source copy owner or it is evident from the scan itself, which could help eliminate duplication. But do we document the publisher (and possible link) or owner (source)? Doug H 16:18, 1 September 2019 (EDT)

Margery Allingham

Our friends at SFE3 have updated their "Margery Allingham" entry. Would anyone be interested in leveraging it to flesh out her ISFDB bibliography? Ahasuerus 13:08, 30 August 2019 (EDT)

I can get that this weekend - I like Allingham anyway. I never think of her as one of ours. :) Annie 13:28, 30 August 2019 (EDT)
Thanks! And if I had a penny for every time I was asked "Wait, what? X wrote SF?", I would have a very impressive penny collection :-) Ahasuerus 14:30, 30 August 2019 (EDT)
I've actually read everything they had added over in SFE3. They just did not register as something I would add here or as something that I would even consider speculative (in my brain, they are in my mystery/crime part of my genres). Then I think about them and I realize that they DO fit. On the other hand, I had the same reaction after I read Reply Paid earlier this year -- I had to think on why we would be here (and once I figured it out (and it was obvious once I thought about it), I even added tags. For the first time in my life I think) But them I read extensively in both genres so "that is not from this genre" does not even register sometimes - it fits in one of my genres. I really need to pay more attention to that while reading early mysteries... :) Annie 14:58, 30 August 2019 (EDT)

"They" They 'They'

For several Kipling stories we now have not two but three SHORTFICTION that represent the title fashioned with double, or single, or no quotation marks. Some double-q-mark are canonical 21309 ("They") 1000842 and some no-q-mark are canonical 78266 97925 1000846. (Some single q-mark are parents with only one child.)

Previously I have used the double-q character where a publisher (or library record) uses the single-q, as one convention among several in a class to which it may not officially belong. Without recommending [a] consistent use of any typographical convention thruout the database, or [b] for all English-language titles, we might recommend [1] that either double- or single- but not both be used for any one title.

Regarding the hierarchy, we might recommend [2] that one among double, single, and no-q be the parent for all related titles (eg, SHORTFICTION, CHAPBOOK, ESSAY, INTERIORART, COVERART).

Perhaps I should have specified that the 1904 Kipling short story "They" &c was that year published in a magazine as They; and collected as 'They' (UK) and as "They" (US trade ed.), US subscription ed. not viewed. And published in 1905 chapbooks as 'They' (UK and US); the same US publisher who re-set the collection did not re-set the chapbook. --Pwendt|talk 18:07, 30 August 2019 (EDT)

--Pwendt|talk 17:00, 30 August 2019 (EDT)

'Romance language' added

'Romance language' has been added to the list of supported languages. Please note that it is only supposed to be used to enter titles written using Romance dialects and less well-known languages not supported by the ISO 639-2 standard. Examples include Picard, Lorrain and various Norman dialects. Ahasuerus 18:13, 30 August 2019 (EDT)

Series Names That May Need Disambiguation

Does someone remember what is the point of this report?

It seems to contain all the series names that have at least one partner that had been disambiguated (and which had not been ignored yet). Our policy (formal or not but implemented in practice) is that in such cases one series remains as the main one named so (no disambiguator) and everyone else gets disambiguated. So these series that are on the list will just need ignoring (and will always just need ignoring). Before I go and ignore all 589 of them:

  • Am I missing something? When do we need to do something with those?
  • If I am not missing anything, do we really need this report?

Thanks! Annie 20:52, 30 August 2019 (EDT)

It's been a few years, so I am not 100% sure what I was thinking when I created the reports. I suspect that the idea was that we have a lot more identically named series than we have identically named authors because series names are, quite frequently, commonly used words. For example, we have 10 series whose name happens to be "The Guardians" and 5 series whose name is just plain "Guardian". Moreover, none is an obvious favorite. Compare and contrast with Stephen King vs. Stephen King (I) vs. Stepehen King (artist) where it's clear which author doesn't need to be disambiguated.
Also, I find that having a disambiguating suffix comes in handy when processing new series. When the time comes to enter Book 1 in Jane Doe's "Guardians" series, the approving moderator will see a yellow warning because there will be no plain "Guardians" series on file. Ahasuerus 13:16, 31 August 2019 (EDT)
This actually makes a lot of sense - that is why I am asking before doing something cardinal. I will see if I can get some of those resolved. Any chance to get a matching Pub Series report? These use even less words usually and get repeated across publishers a lot. Annie 01:52, 5 September 2019 (EDT)
Sounds good; FR 1300 "Create a cleanup report to find pub series needing disambiguation" has been created. Ahasuerus 21:23, 5 September 2019 (EDT)
Done -- see this post for details. Ahasuerus 21:59, 4 October 2019 (EDT)

The Warrior's Apprentice Baen edition cover art

Hi, I merged the existing cover art title credited to Alan Gutierrez with the other one credited to Gary Ruddell: the cover artist was identified as Ruddell & the entries for the two printings preceding the 7th thus must have been erroneous. There was no note for those as to where the cover art credit stemmed from. Christian Stonecreek 10:10, 2 September 2019 (EDT)

The assumption is that unless otherwise stated it is from the pub. It would have been better to have checked with the verifiers before doing this. Willem's response to TAWeiss (see this discussion) implies the cover art for his printing was credited as Gutierrez in the publication. It is not unknown for publishers to change the cover and forget to update the credit until a later printing. You can explicitly ask him if you wish to double check, but otherwise, this needs to be reverted and a variant established instead. -- JLaTondre (talk) 10:18, 2 September 2019 (EDT)
I unmerged the titles again, added the right credit and varianted it to the Ruddell entry. Also added pub notes. --Willem 10:45, 2 September 2019 (EDT)

Handling erroneous tags

The way the current version of the ISFDB software ("ISFDB 2.0") works, almost all types of database changes are entered as "submissions" and have to be approved by a moderator. The major exceptions are verifications, votes and title tags. They are all user-specific, which is why Al and I originally thought that we wouldn't need moderator oversight for them. In the case of title tags we were also leveraging other Web sites' (Amazon, Goodreads, etc) experience which suggested that "crowdsourcing" tags worked well even without moderator oversight.

Overall it has worked reasonably well with a few caveats. First, we are primarily a bibliographic database, so tags like "read in 2013" are not something that we normally want to display to the world at large. A few years ago we got around this problem by letting moderators change tag status to "private".

Second, we never reached the volume that is required to make "crowdsourced" tags reliable. The vast majority of the 7% of our title records that have tags have been tagged by just one or two people. An incorrect tag entered by a single user is not too bad when dozens of other users have entered valid tags, but it becomes a problem when there are no valid tags to offset it.

Based on Christian's recent experience with incorrectly tagged titles, I would like to propose that we create a new moderator-only Web page. It will display a list of currently entered user/tag pairs for the selected title record, e.g.:

This will let moderators contact taggers and ask them about questionable tags. The proposed Web page will also let the reviewing moderator remove invalid tags for users who are not moderators.

How does it sound? Ahasuerus 12:29, 3 September 2019 (EDT)

I'm not really clear on tags, having never used them here (either entry or following). If you put this on the moderator's forum, I'd guess you wanted to know if such a tool were useful, but on a public forum I'm thinking you're asking if editors want moderators to perform this function. Doug H 08:18, 4 September 2019 (EDT)
Significant software changes are usually discussed on the Community Portal even if they mostly affect moderators. You never know when a non-moderator may notice a potential pitfall. Ahasuerus 12:48, 4 September 2019 (EDT)
I'm not sure about adding policing of tags to the list of moderator tasks, but as a tool for determining something and correcting it, it beats direct database manipulation. Doug H 08:18, 4 September 2019 (EDT)
It's possible to delete erroneous tags directly, but I should have mentioned that I haven't done it in years. Direct database manipulations are risky, so I rarely attempt them. Ahasuerus 12:52, 4 September 2019 (EDT)
I'd suggest that the deletion of a tag should be 'logged' for the Changed Primary Verifications. Doug H 08:18, 4 September 2019 (EDT)
Keep in mind that title tags are associated with titles, not publications. Title changes (edits, variants, etc) are not captured by the Changed Primary Verifications report at this time. Changes to tags would be even more difficult to link to verified publications because tags do not go through the standard submission approval process. Ahasuerus 12:45, 4 September 2019 (EDT)

(unindent) Seems good to me. In addition to this, two things has always bothered me as far as tags were concerned : 1) the fact that many "private" tags do appear from time to time, drowning the others completely (see here for instance); Linguist 10:43, 4 September 2019 (EDT).

Is the problem with this author the fact that tags like "C1 Nanzan 52" can be viewed by all users? If so, then a moderator can change their status from "Public" (their current status) to "Private", at which point only the tagging user will be able to see them. Ahasuerus 12:40, 4 September 2019 (EDT)
Oh ! I hadn't been aware of that… I now sadly realize that being a moderator doesn't mean being omniscient… ;o( ! Linguist 04:14, 5 September 2019 (EDT).

and 2) the number of quasi-identical tags (e.g. ghost / ghosts, werewolf / werewolves, fish-men / fishmen, etc.) which should be merged (if only it were possible…). Linguist 10:43, 4 September 2019 (EDT).

FR 911, "Allow moderators to edit and merge tags", should help address the issue of merging tags. We'll get to it yet! :-) Ahasuerus 12:42, 4 September 2019 (EDT)

But I suppose we'll just have to grin and bear it… Linguist 10:43, 4 September 2019 (EDT).

Do we really want to enhance tag support? What if we would not have any tags at all? Would that be a big loss? - or would it actually be a win - evil grin -:)? As far as I'm concerned, there's not much benefit in tagging, let alone start moderating them. Another argument against ISFDB tags altogether is the nonexistent support for them from our user base (see the volume - tagging is available, but just not used by our users - exceptions notwithstanding). MagicUnk 11:39, 4 September 2019 (EDT)
I should note that the fact only 7% of our titles (116K out of 1.66M) are tagged is a bit misleading. Certain title types - covers, essays, interior art, etc -- are rarely tagged for various valid reasons and variant titles can't be tagged at all. The 206,000 tags that we have is a fairly significant number since we have 178,000 novels and 464,000 short fiction works. Ahasuerus 13:01, 4 September 2019 (EDT)
How many of those tags are coming from the robots (Fixer and the older ones)? Annie 13:38, 4 September 2019 (EDT)
Well, I am responsible for 70,591 of the 206,000 tags that we have on file. Since most of my tagging is related to Fixer's activities, I guess the answer is "Around one third"?
Also, as I mentioned during the last iteration of this discussion, I find tags to be particularly useful in borderline cases like "magical realism", "surrealism", etc. It's a quick way to indicate why the title is in the database. (Of course, there are times when things are even muddier and I end up adding a note to the record explaining what we know about the title and what our sources are.) Ahasuerus 15:38, 4 September 2019 (EDT)
I was just curious - expected it to be even higher :) I agree that they are useful for these cases - I just do not want to end up in a "this is surrealism, no it is "magical realism" kinda wars. As long as we agree on what is removable and what is better to stay on, I am all for it. And we do need a way to clean after both mistakes and after non-so-nicely done tags (for one reason or another). Annie 15:45, 4 September 2019 (EDT)
True, moderators will need to be careful. Even common words may have different denotations when used by different people. For example, when a romance reader says that a story is a "fantasy", it may be a reference to "erotic fantasy" or to a trip to a billionaire's private tropical island. Back when Fixer was just starting, it took me a while to figure out why he was grabbing so many non-SF romance/erotica books... Ahasuerus 09:21, 5 September 2019 (EDT)
Implementing moderation is not going to change that (au contraire). We should just kill tags outright as our active editors base is just too small to make it viable. I would argue that we need to grow our editor base first and encourage them to actively start tagging before thinking in implementing additional tag functionality. Just my 2cents though MagicUnk 11:39, 4 September 2019 (EDT)
Well, it would help a lot! And tags are a wonderful way for users to become aware of titles they may be interested in, that's the reason they were invented for. Stonecreek 12:03, 6 September 2019 (EDT)
The primary concern here is accuracy. There are certain areas of the database that are relatively rarely used yet we have spent a significant amount of time and effort ensuring that the data that we do have is accurate. For example, less than 1% of our titles is "non-genre", but at one point I spent multiple man-weeks cleaning up the code to make sure that the database model could adequately support non-genre titles. Ahasuerus 13:06, 4 September 2019 (EDT)
Killing something just because noone does it is a bit... premature. I am not a huge fan of tags (mainly because of how I use the DB) but they can be valuable. And if you look at 3 years ago, someone may have proposed to kill the language field as well - it was not really used either. Things change - we need one editor to make it their pet-project and our numbers explode.
On the other hand, what worries me about tags is that they can be subjective. Especially around the borders of the sub-genres. I do not want to see a moderator deleting a bunch of "fantasy" tags because they think the book is something else (and vice versa). It won't be malicious but... most of us do have somewhat strong personalities and things can get heated. :) Merging was already brought up. Annie 13:38, 4 September 2019 (EDT)
I would only delete tags that are obviously erroneous, like the two I found (see over at Ahasuerus' talk page). If the editors are still active, communication about it should be mandatory and maybe it'd be possible to install a mandatory note to be filled in for the reason of deletion. Or, let's have a mandatory note on the community portal for tags to be deleted in case of inactive editors. I don't expect to encounter masses of erroneous tags, but the ones that are in the db still need fixing, I'd say.
I think the tags are one of the advantages of ISFDB: personally I'm more interested in certain authors but am also eager to encounter new ones, and if I find somebody with an interesting theme / tag (that may possibly have gained a high voting), I'll may want to give the text a try. Stonecreek 13:38, 5 September 2019 (EDT)
I was just thinking aloud through implications -- best laid plans tend to end up in disaster some times. I am sure that noone that is here today will go into tag-editing war. A few years down the road when everyone forgets why we can moderate them? Different story. :) Mandatory notes before deletion will help. Keeping a list of deleted tags somewhere so we can restore if needed will also help. But I do agree with you in general that we need the ability to remove tags that are really really wrong. Annie 12:23, 6 September 2019 (EDT)
It would be possible to capture, store and display deleted tags along with moderator notes. However, it would take significantly longer to implement than a simple "display/remove tags" page.
One temporary compromise would be to make this functionality bureaucrat-only. We are probably talking a few dozen tags a year, which shouldn't be too onerous. Ahasuerus 13:41, 6 September 2019 (EDT)
How easy will be to change the access-levels later if we decide to - aka build for bureaucrat-only, switch to moderator-also if the numbers get too big? Annie 13:46, 6 September 2019 (EDT)
It would be a simple change. Ahasuerus 14:01, 6 September 2019 (EDT)
I wonder if changing these from Public to Private won't be a good enough alternative for now? Annie 12:23, 6 September 2019 (EDT)
Unfortunately, erroneous tags can be perfectly valid in other contexts. For example, one of the tags that prompted this discussion was "parallel universe" and we wouldn't want to make it a "private tag". Ahasuerus 13:37, 6 September 2019 (EDT)
Yeah, somehow my mind blanked that part. You are indeed right. Annie 13:46, 6 September 2019 (EDT)
Bureaucrat-only is a good compromise in my opinion. Tags are very useful for anyone interested in a special theme or a certain author, but if you'd be interested in stories that deal with parallel universes and find titles that are tagged erroneously with that label, you are bound to lose some trust. Stonecreek 14:00, 6 September 2019 (EDT)

(unindent) OK, FR 1303, "Allow the removal of erroneous tags", has been created. Ahasuerus 14:50, 19 September 2019 (EDT)

Two author reports

Do we really still need both these reports:

While I had seen entries in just the first one once or twice, it had not been for a while and it seems like a waste to go through the authors twice. Maybe time to see if we can combine them? Annie 01:56, 5 September 2019 (EDT)

Hm, that's a very good question! If I recall correctly, the original reason why they were "separated at birth" was that one of them allowed moderators to "ignore" author records while the other one didn't. However, their logic has been tweaked a few times and neither one supports the "ignore" functionality at this point.
Checking the code behind the reports, I see that one of them is a superset of the other. There are some minor display differences, but I don't see anything that should prevent us from merging them.
FR 1299 "Merge 2 'Invalid Directory Entries' reports" has been created. Thanks! Ahasuerus 13:18, 5 September 2019 (EDT)
Can we keep the format of 189 (with the working language)? :) They did make sense when we had hundreds of non-Latin entries (I think the latter was deployed when we were cleaning the accented characters from the authors' directory names(?) but I may be wrong - the other one is one of the very old ones). Annie 13:32, 5 September 2019 (EDT)
Yup, the current plan is to keep the "Working Language" column. Ahasuerus 13:55, 5 September 2019 (EDT)

(unindent) Done. The remaining report has been changed to display "Working Language" values. Ahasuerus 21:55, 4 October 2019 (EDT)

Wiki page for table of translations

I have set up a wiki page here to help differentiate translations of Cinq semaines en ballon and help editors locate the correct title to add their publication to. I'd like to use it to as a template for similar pages for most of the other (50+) titles by Jules Verne. Before replicating this, I'd like some feedback in general and on a couple of particular questions. To whit:

  1. Should the translated text be in quotes? Many of the other books include dialogue already in quotes. Doug H 10:20, 5 September 2019 (EDT)
I do not see why - it is in its own column, so does not really matter. I would not use quotes if I were you :) Annie 12:47, 5 September 2019 (EDT)
  1. Should the translation follow the paragraph structure of the published form? Some translations (e.g. Mysterious Island) begin with about five paragraphs consisting of three or four words. Doug H 10:20, 5 September 2019 (EDT)
When we know what it is, why not? Makes those translations immediately obvious.Annie 12:47, 5 September 2019 (EDT)
  1. These are currently ordered by the earliest date for the translation, with the exception of the unspecified text. Other options include alphabetically by translation (to make searching for the right variant easier), and by translator (making searching easier where the translator is known - an not 'unknown'). Another option would be to split entries by title and duplicate the translation information and sort by title alone. What order would prove most useful? Doug H 10:20, 5 September 2019 (EDT)
I like the dates order Annie 12:47, 5 September 2019 (EDT)
  1. What should the order of languages be? As an English speaker and this being an English language site, I put it first, then followed alphabetically, which happened to be purely alphabetical in this case. One option is in decreasing order of the number of translations. There's also by the number of translation/title combinations. Or even in order of the number of publications (not visible, but I have the data).Doug H 10:20, 5 September 2019 (EDT)
I like it as it is now - and the menu at the top will allow jumping down. Inside of a table - strictly by date I would say. Annie 12:47, 5 September 2019 (EDT)

Your feedback would be greatly appreciated, as I've gotten too enmeshed to have a wider perspective. Doug H 10:20, 5 September 2019 (EDT)

Some notes above. That kinda illustrates my point from a couple of days ago about editors and per project - once someone starts working on something, we end up collecting a LOT of information. :) One thing though - instead of separate pages, I will keep the different titles per language together. Think of a Russian speaking editor who is trying to sort out the Russian titles - it is a lot easier to work off one page than moving between 50 or so - especially when working on omnibuses. Which begs the question on how to split and my gut feeling is pure alphabetical per language: A-D, E-G and so on (in whatever increments we need). Annie 12:47, 5 September 2019 (EDT)
Curious about where you're going with this, or rather where you think someone is coming from. Is your hypothetical user trying to figure out which French title their Russian title is a translation of? And that the title has never appeared before - otherwise they could do a text search on the Jules Verne Summary Bibliography page - same as I do when I want to find the original French title for something like "The Clipper of the Clouds"? ../Doug H 13:07, 5 September 2019 (EDT)
Length of that page - if we get 50 titles, 100 translations per title, we will need a split somewhere. And the Russian are an easy example because they tend to have as many translations as English does. And I like seeing all titles in the same language on the same page - easy to spot what someone may had forgotten to add. :) Annie 13:11, 5 September 2019 (EDT)
Are you saying the Summary Bibliography page might get too long and need to be split? This wiki page will do nothing for that. Also, isn't your scenario covered by the Preferences - Translations - Selected? Pick Russian and view the page and see all Jules Verne's Summary Bibliography in the French with only Russian translations? While a page per language (or language group - [would it be German or Deutsche?]) makes some tasks easier, verifying its correctness would be really tough - you'd end up having to scan the 50 pages for each language. Or generate a query for periodic reviews. But the same query would resolve the issue of seeing them together. So who makes the query - the maintainer or our Russian editor? And what if I only get the Extraordinary Journey series done, what happens to the other titles, or short stories. I'm convincing myself that keeping it to one wiki page per title with all languages is preferable. How's by you? ../Doug H 14:01, 5 September 2019 (EDT)
The wiki page, not the summary page :) The point of the wiki page is to give you an easy reference, right - that does not require either DB knowledge or opening 20 pages to see the beginning translations? I may be overthinking it. If you want to go title by title, that also works. I just would prefer it to be language based and not title based (but it is not my project). And once we have it, we can always reorganize. So... just thinking aloud :) Annie 14:11, 5 September 2019 (EDT)
Ah, you were referring to your suggested single page for all Jules Verne translations, not my suggestion that the Russian editor could find a title by searching the Summary Bibliography page using a browser search to find which French title corresponded to his Russian one. Different perspectives - my approach is intended for people wanting to add a publication and helping them locate the correct title, based on the actual text, not just the title, or even the translator, given there are sometimes multiple unknowns, each with a different translation. And the only reason for not following paragraph structure was to keep the page from getting too long. :) ../Doug H 14:29, 5 September 2019 (EDT)

Internet Archive "hotlinking"

Perhaps this is a better discussion for rules or moderators but I thought everyone might like to chime in on this.

We currently detail which sites we allow images to be hotlinked from at: Template:Image Host Sites. I was wondering if we could get the Internet Archive added to this list. We already have the Open Library which is one of their projects but I was interesting adding magazine covers like:

I realize in this example Starlog it not considered fully an "in genre" magazine and thus we often do not concern ourselves with providing covers (much-less full contents) but this is just an example.

Notice there is some information about what not to link to here: https://archive.org/services/docs/api/items.html#archival-urls This is why I mentioned:

and not:

which is the target of the redirect (at least for now; presumably they do not want people linking to this as it might change)

It should also be noted this has come up on some of their online discussions before and they have approved it, e.g.:

Do we need to specifically ask them (and is someone volunteering) or can we have them added to the list of possible hotlink hosts we accept?

Thank you, Uzume 17:38, 5 September 2019 (EDT)

The linked discussion and https://archive.org/services/docs/api/items.html#archival-urls suggest that stable Internet Archives look like https://archive.org/download/<identifier>/<filename> . However, the Starlog scover scan URL linked above is https://archive.org/download/starlog_magazine-004/004_jp2.zip/004_jp2/004_0000.jp2?ext=jpg , a different format. Also, it requires a query string, "ext=jpg". Is there any kind of Internet Archive documentation about this format? Ahasuerus 16:41, 9 September 2019 (EDT)
Actually that is the filename/filepath. "004_jp2/004_0000.jp2" is the filepath inside the 004_jp2.zip file. I could not find any documentation on ext query string that seems to convert the file type. We could link to the .jp2 file but I found it did not render in my browser (so was not a good choice as an img src). You can poke around in here to get the idea how I came to the link I provided above: https://archive.org/download/starlog_magazine-004 As a test, I made this submission. Uzume 17:23, 18 September 2019 (EDT)
I am putting this on hold. We still do not have permissions to link but I will leave it so Ahasuerus can see how it looks like - although if you wanted to use it as a test, your moderator note should have added that to the link :) Annie 17:34, 18 September 2019 (EDT)
I thought there were more than adequate notes here so just linked to here in the mod note (and I did not expect it to be approved directly; thanks for holding it). As for a perhaps more realistic example (instead of Starlog which is only partially here under acquisition rules), I was thinking of something like https://archive.org/download/equality00belluoft/equality00belluoft_jp2.zip/equality00belluoft_jp2/equality00belluoft_0001.jp2&ext=jpg for 270798. Uzume 17:59, 18 September 2019 (EDT)

(unindent) I guess we have two overlapping questions here:

  • Are we allowed to deep-link to images hosted by the Internet Archive?
  • Are their images and image URLs stable?

Historically, the main problems with deep-linking have been:

  • bandwidth
  • revenue

In the not so distant some past popular sites like Wikipedia didn't want third party sites to link to "their" images because it increased their hosting costs. This issue appears to be less important now that bandwidth is less expensive.

Revenue is something that we have run into with SFE3: their sponsoring organization wanted us to link to a separate Web page which was set up to make it easier for customers to buy books.

In the case of the Internet Archive, their staff posts suggest that they do not have bandwidth or revenue problems with deep-linking. Uzume's research suggests that the URLs that he uses are at least moderately stable.

Based on the analysis above, I wouldn't be opposed to adding "archive.org" to the list of supported third party sites, although an explicit e-mail permission dated "2019" would be nice to have.

That said, do we expect a significant number of links to their site? If not, it may be easier to upload the images in question to the ISFDB server and link them. Ahasuerus 15:03, 19 September 2019 (EDT)

As a workaround, I have just been pulling Internet Archive images across to their Open Library project and then hotlinking here (since we already allow that). That works alright for books as I just have to ensure the right entry exists there but I am not sure about magazine covers which would likely not be in their Open Library project. Uzume 12:36, 22 September 2019 (EDT)

Not One of Us – magazine or fanzine?

I wonder do we need to make a decision about whether we list the all-fiction/poetry publication Not One of Us as a magazine or a fanzine? From 1986–2001 we have it listed as a fanzine, then from 2002–2018 it is alternately a magazine or a fanzine. Their website refers to it being "a hardcopy zine", with a pull-quote saying it's a "stalwart of the zine scene", yet their Guidelines page has "The editorial philosophy of the magazine...".

We also have a small problem with format, sometimes A5 but mostly octavo, although from the website's description "a digest-sized (5.5 x 8.5 inch, 52-page) publication" it is clearly octavo.

All this makes for inconsistency and I think we could present the information better. The majority of publications are unverified, so I'll spend a bit of time knocking the series into shape if we can come to a group decision on the Magazine/Fanzine question – my own preference would be for Magazine. I'm particularly looking for feedback from verifiers Hkauderer and Kevin Hardy, although I'm uncertain if either of those editors are still around. Thanks. PeteYoung 08:10, 6 September 2019 (EDT)

I would have never thought that it is not a magazine. Just as a data point, ~15 years ago (probably a bit more), Not One of Us was one of the not so many English language small magazines which were available from a distributor website that was willing to ship to Bulgaria - together with some other books from small presses. Everything else on their list of magazines was a clear magazine, this one was in the same section. Does not mean that it could not have been something else but... I probably should find the boxes with all magazines next time I am back at my mother's apartment. Annie 11:23, 6 September 2019 (EDT)

Deprecating {{A}}

In Help:Using Templates and HTML in Note Fields#Linking Templates we list {{A}} as a supported template stating:


[...]
At this time the following linking templates are supported:

Template Functionality Example
A Links to an Author record within ISFDB using the author's name {{A|Jules Verne}}

[...]

However, later in the same page at Help:Using Templates and HTML in Note Fields#Links to Other ISFDB Records we state:


[...]
If you choose to link to another ISFDB record, avoid using the following types of links:
[...]


[...]

Should we deprecate and/or update/replace {{A}}? Thank you, Uzume 19:14, 8 September 2019 (EDT)

"A" links to the search page, not to the author page itself - so if you pass "Test" as a parameter, it goes to http://www.isfdb.org/cgi-bin/se.cgi?arg=Test&type=Name&mode=exact. There is just a forward in the Advanced Search that IF there is only one result, it opens the author page instead of the results page (using the ID and not the name). Try the A template with an author that does not exist :) So A is quite safe. Annie 19:40, 8 September 2019 (EDT)
PS: If you do not believe that the template is tied that way, look at any note with it and hover over the link or view the source code :). It effectively links to the author but not by getting the name and creating a URL out of it. Annie 20:20, 8 September 2019 (EDT)
That's right. The "A" template works fine with non-Latin characters and so do all other templates. Ahasuerus 21:18, 8 September 2019 (EDT)
Oh, I never said it did not work just that it did not link by author id. The link section recommends we should link by the author id and not the author name itself (although we guarantee those are unique). Perhaps we should recommend linking by author id *or* the exact search? Also since we have redirects why not make the author lookups that use a name instead of an author id redirect to the exact search and/or at least redirect to the author pages referenced by author id (for cases that don't have Unicode issues and currently work). Uzume 15:08, 9 September 2019 (EDT)
I mean why not have:
redirect to:
to solve the problem or at least directly to (since "Ray Bradbury" stays within Latin-1) to:
So when people copy the URL it causes them to not want to link to name reference entry (because it gets redirected).
I just am concerned why the difference in the same page about how to reference an author. If it can be solved in code—so be it. Uzume 15:16, 9 September 2019 (EDT)
Let me try this again because I do not think that you read any of the messages (or clicked on any of the links. :)
We do NOT link to http://www.isfdb.org/cgi-bin/ea.cgi?Ray_Bradbury via the template. We link to http://www.isfdb.org/cgi-bin/se.cgi?arg=Ray Bradbury&type=Name&mode=exact. Which searches and then links based on the ID (to http://www.isfdb.org/cgi-bin/ea.cgi?194), not using the name.
Just go to ANY of the notes that have a name and look at where the address is pointing to. The format you are concerned with is not used at all.
Linking to an ID when the ID is not presented will mean that the lookup needs to be done during the save and replaced (as opposed to building a URL using what the user presented). Doable? Yes. But what do we do when there is no user to be linked? Now it sends you to the search page (so if one day there is one, it will connect). And how about cases where the author ID changes - who is going to update all the links? The warning for the "bad URL" is valid but the template does not use it so... it is not relevant. :) Annie 15:40, 9 September 2019 (EDT)
I think you did not read what I am trying to say (perhaps I worded it poorly) and that is there is a discontinuity in how these two situations are handled. I like the way the template links to the exact search (and forwards to the author id URL). I just think that case and the one where an author name (vs. its id) is in the "ea.cgi" link (which is discouraged) should be handled the same way. So why not make that redirect to the exact search URL (or directly to the author id URL since the exact search often ends up there anyway). This would further dissuade others from using the author name in the "ea.cgi" link as the redirect will cause the URL to not stay in the browser's address bar. That is what I meant by solve issues with code vs. my original idea to perhaps have the templates link to the author id (necessitating a change and possibly deprecating {{A}}).
I was never confused how they worked technically (I can directly read the Python and SQL code), I just feel they ought to be handled in a similar manner. Since we are on the topic if the deprecated author name "ea.cgi" (and other author page) linking. It should be possible to log such accesses (and any HTTP referer [sic]) and create something like a nightly report such that others can then investigate and attempt to rectify such inbound links from elsewhere. We might also be able to warn the user using such an inbound link and perhaps they would be able to change the external link source. Uzume 16:42, 10 September 2019 (EDT)
I did read what you said - having the template being mentioned all over the place confused the whole thing a lot though. :) Deprecating the template won't do anything for what you are trying to solve here - because the template is technically the correct way to do these links. :)
So to summarize without all the irrelevant parts and window dressing above: you propose ea.cgi to be modified so that when someone uses a name in the URL, it emulates the template and goes via search with the name (thus going for the ID link at the end). Is that the current state of the idea? Annie 17:24, 10 September 2019 (EDT)
I actually looked into this issue back when the Search software was rewritten and templates were implemented. I ran into some technical issues and ended up abandoning the effort. It may be worth trying again. Ahasuerus 17:46, 10 September 2019 (EDT)
@Annie: Yes, that is exactly what I am saying (and it applies to the other author page formats as well, like awards, alpha, chrono, etc.). It might also be useful to document the ability to link to the exact author search but I am not sure we want to support such inbound URLs. One can already see the issue of author name linkage in ea.cgi: wikipedia:Special:LinkSearch/www.isfdb.org/cgi-bin/ea.cgi (be sure to page down past the author numeric IDs; Mediawiki does not allow more complex external link searches that would let me filter those out). Uzume 17:16, 18 September 2019 (EDT)
Thanks, that's a useful URL to be familiar with. I suspect that officially supporting deep links using our Search URLs would invite problems. We have changed the URL format a few times and may change it again, so URLs are not guaranteed to remain stable. Ahasuerus 15:09, 19 September 2019 (EDT)

If we do decide to work on making redirects for these (e.g., the creation of an FR, etc.), lets not forget this needs to also be extended to series, e.g., currently this is still legal (though methinks it too should be discouraged): The Stainless Steel Rat should redirect to The Stainless Steel Rat I am not sure if there are other similar candidates. Uzume 00:35, 1 October 2019 (EDT)

Award Name Changes

The editor for Analog has announced that the John W. Campbell Award for Best New Writer has been renamed as "The Astounding Award for Best New Writer". Those in charge of two other awards have also been discussing name changes. The Gunn center has announced that the John W. Campbell Memorial Award will be renamed, but the new name has not yet been chosen. The administrators of the James Tiptree, Jr. Award have discussed changing the name and have decided not to do so at this time, though they describe their thinking as "ongoing and tentative" and the name may change in the future. I've been thinking about how we should handle these changes in the database. All three of these awards have several years of history and I would suggest that we keep the existing award pages as is for those years under the old name. Going forward I would suggest a new award page for the new name with links in the notes of each award page linking to the other. That way folks searching for either name would be able to find things. I don't know if we want to set up a new page for the Astounding award now, as it would be blank until next year when the nominations are announced. We will need to wait for the new name for the second Campbell award and for the Tiptree, only if they decide to change the name. Are there any other ideas on how to reflect this award data? --Ron ~ RtraceTalk 22:45, 8 September 2019 (EDT)

I can think of at least one award whose name has changed since it was created, the Ditmar Award. It was originally known as the "Australian Science Fiction Achievement Award". The full name that we currently use is "Ditmar Award / Australian Science Fiction Achievement Award" while the short name is "Ditmar". We could use a similar approach in similar cases, although it may become unwieldy when dealing with longer award names: "The Astounding Award for Best New Writer / John W. Campbell Award for Best New Writer" may be a bit too much.
Alternatively, we could create new award types and document the relationship in Notes. Ahasuerus 23:14, 8 September 2019 (EDT)
If that becomes highly common and complex we might eventually decide to support some sort of award relations not unlike our current pseudonym and title variant systems (I can already see where this would be very useful to support publisher relations of some sort). Uzume 17:04, 18 September 2019 (EDT)
Well... The "variant title" system lets us capture title/author information as it exists in publications as well as its "ideal" or "canonical" state. That's a good thing, but it also adds a great deal of complexity to the software.
It's been occasionally suggested that we use a similar system for other parts of the database, e.g. to capture publisher names both as they appear in publication and in their "canonical" form. It's doable, but it would require a significant amount of work, both on the software side and on the data entry side. We would also need to make sure that our design is very solid because we really wouldn't want to do re-do again. For publishers, it would mean figuring out how to handle imprints and books co-published by multiple publishers, which is liable to add extra levels of complexity. Ahasuerus 17:40, 19 September 2019 (EDT)
I understand such a change is nontrivial but we have made nontrivial changes in the past and I am sure they will happen in the future. Are we ready for this type of change now? I do not know but I thought I should bring it up as it is a possibility that impacts the issues being talked about. As a side note, I got a good laugh out of thinking about "canonical publishers" (isn't that some sort of oxymoron?). Uzume 12:30, 22 September 2019 (EDT)

Final Fantasy

I think I got them all. "The Spirits Within" is a weird one. I've seen a number of places that Dean Wesley Smith wrote the novelization (with cover images and everything), and then other places that say John Vornholt wrote it (also with cover images). Both have the same ISBN, and it hasn't been verified here, so I have no idea which might be the actual author. Any ideas which is actually correct? ···日本穣 · 投稿 · Talk to Nihonjoe 00:35, 10 September 2019 (EDT)

After digging a little bit more, it looks like Vornholt did a juvenile novelization, and Smith did an adult novelization. It would be helpful if the covers indicated this, and if Amazon didn't have the entries merged. ···日本穣 · 投稿 · Talk to Nihonjoe 02:09, 10 September 2019 (EDT)
Well, where will be the fun in that? :) Annie 02:37, 10 September 2019 (EDT)
Novelizations have always been iffy, e.g. see this UK novelization of Capricorn One vs. its US counterpart. However, things have been slowly getting worse over the last 10-20 years. For major intellectual properties, the rights owners routinely commission 2+ different novelizations for different age groups. Factor in the fact that novelizations aimed at younger children tend to obscure their authors and you end up with a big mess. Ahasuerus 10:28, 10 September 2019 (EDT)
That is highly confusing, especially since the Dean Wesley Smith adult novelization was translated to Japanese (instead of creating Japanese novelizations directly from the Japanese movie) and the NDL indicates all three publications are children's literature. Uzume 16:46, 18 September 2019 (EDT)
Wouldn't be the first time people varied on whether something was or wasn't for kids. Until we get PVs for them, we can't really do more than what we have. ···日本穣 · 投稿 · Talk to Nihonjoe 02:10, 19 September 2019 (EDT)

pb, tp and the dropdown

After explaining/clarifying for a third time this week that "pb" does not really mean paperback, it kinda reminded me that we really need to do something about this - or new editors will continue to be confused. So why don't we change the drop down values:

  • pb -> "pb (mass market paperback)" or even "pb (7'x4.25' / 18x11 cm or smaller)"
  • tp -> tp (7'x4.25' / 18x11 cm or larger)"

We do have the space (the audio formats are long) so... why not help the editors visually? Other idea for naming are welcome. Annie 16:13, 15 September 2019 (EDT)

I've always thought of pb as pocket book. Not that it is really any better defined but narrows down the argument by eliminating the trade-sized publications. ../Doug H 22:13, 15 September 2019 (EDT)
While closer, that will include a lot of Eastern European books which are too big to be called pb in the DB - even with generous exceptions (apparently we used to have bigger pockets than the Western world - or something). But still - it will be better than now (and this is only for the front end - the codes behind the scenes are fine) :) Annie 22:57, 15 September 2019 (EDT)
That's not only the case for Eastern Europe but for Western Europe as well (maybe with the exception of some islands in the West): we had this discussion a while back. So this specific dropdown would also be misleading. The best I can think of is an explaining comment that these measures are valid for (most of) the English publishing world, but may vary for other countries. Stonecreek 02:22, 16 September 2019 (EDT)
And put the comment where? :) If people will read the help pages, that is easy enough - we have the info there. They don't. So I am thinking of changing the drop down so it is easier to see that this type is not what they think it is. Annie 02:38, 16 September 2019 (EDT)
I just saw that we have that infobox right near the 'Format' field (when you come on the question mark). This one should be specified, I'd say. Christian Stonecreek 15:10, 16 September 2019 (EDT)
Sure, it is there - but people will still not look at it - or hover on it - hovering from a touch screen is a bit... problematic :) The list looks logical - and if they press "p" to get to "paperback" and see "pb", most people won't look further. Not what we wish people were doing but no reason to just hide our heads in the sand and pretend that it is not happening. The field looks self-explanatory - and most people do not read the help pages for this kind of fields. Annie 15:31, 16 September 2019 (EDT)
Which one would you select for wikipedia:Bunkobon? I usually go with "pb" since it is paperback A6. It would be nice if we had "A6" since we have "A4" and "A5". Uzume 16:52, 18 September 2019 (EDT)
You are mixing up things here - you cannot use A4/A5 for books under the current rules. Look at the help page. We have clear separation between formats for magazines and formats for books - the A4/A5 formats are ONLY for magazines so even if we had A6 in the magazines section it would not have been the correct format for a book. So yes, a paperback book as small as that one is "pb". Does not mean that we do not have a handful books of each of the A4/A5 formats (uncleaned data, magazines converted to anthologies, stuff that was just missed, special cases or 3 and so on) but technically, the magazine formats should not be used for anything besides magazines and fanzines. Until we decide to change the rules anyway.
However the thread above is not about changing the rules - it is just for providing a visual help to editors so let's not go into "let's change the formats" discussions. If you want to reopen that can of worms, start another thread. :) Annie 23:11, 18 September 2019 (EDT)
I was not confused nor soliciting for rule changes as much as just underscoring the state of things as it applies to a certain common publishing format by asking a rhetorical question (hoping to ensure such were considered). My point was to perhaps include "bunko" along with "mass market" in the description; something like:
pb -> "pb (mass market/bunko paperback; 7'x4.25' / 18x11 cm or smaller)". Uzume 12:11, 22 September 2019 (EDT)

(unindent) Getting back to the "Format" drop-down list, it would be possible to make each choice more descriptive along the lines of "tp (7'x4.25' / 18x11 cm or larger)".

However, keep in mind that we already have a few different ways of conveying this information to our users. On the publication display page we have mouse-over help for each format code. For example, if you hover your mouse over the question mark next to "pb" on this page, you will see "Paperback. Typically 7" by 4.25" (18 cm by 11 cm) or smaller, though trimming errors can cause them to sometimes be slightly (less than 1/4 extra inch) taller or wider/deeper."

When editing a publication record, the blue bubble next to the word "Format" says, among other things, "pb for 7" by 4.25" (18 cm by 11 cm) paperbacks".

In other words, we already display this information in 2 different places, although the wording is somewhat different. Displaying it yet again doesn't seem like the best way to handle the problem. Perhaps we could use the empty space to the right of the drop-down list to display a message along the lines of "Hover your mouse over 'Format' on the left for more details"? Ahasuerus 15:59, 20 September 2019 (EDT)

And my point is that people do not hover over things or read help pages for things they believe to be intuitive and clear - we can have it in 10 places, put a "hover for details" in 10 more and people still won't do it because they do not think they need details because "pb" sounds like the logical choice. People see "pb" and are done with reading - we may have it in 2 places but people just do not look there. Annie 17:00, 20 September 2019 (EDT)
I am pretty sure there is a really good British joke about how much people hover over things in here. Uzume 12:14, 22 September 2019 (EDT)
The problem is actually only the fact that in the help pb and tp is defined with the length and width and that is apparently wrong (Google translator).--Wolfram.winkler 04:37, 23 September 2019 (EDT)

Custom database query request

Earlier today I received the following e-mail request from the SF reviewer James Nicoll:

Is there a way to construct a search of isfdb so that it returns a list of the Best Novel Hugo for each year, with a list of the cover artists for the American editions of the stories in the first year of publication? (basically, looking for patterns in cover art and nominations)

The short answer is that yes, it should be possible, but it would require a custom database query. I haven't been feeling well lately, so I am not in a good position to create one. Would anyone be interested in giving it a try? Ahasuerus 14:20, 16 September 2019 (EDT)

See the following table. There are some caveats:
  • It is using the title id the award is linked to. It could be expanded to look for variants / parents in case also appeared under different form in that time frame.
  • It does not include serialization. Some of the early ones were in magazines. It could be expanded to include those, but the cover would not necessarily be for the story and the artist would likely change over the serialization.
  • It bases it being an American edition of the price being US $. It therefore ignores pubs w/o a price.
  • It does not include the Retro Hugo, but that could be included.
If any tweaks are desired to the above caveats, I will see what I can do. -- JLaTondre (talk) 21:16, 16 September 2019 (EDT)
Award Year Author(s) Title Pub Year Publisher Price Artist(s) Image
1959 James Blish A Case of Conscience 1958 Ballantine Books $0.35 Richard Powers Image
1960 Robert A. Heinlein Starship Troopers 1959 G. P. Putnam's Sons $3.95 Jerry Robinson Image
1961 Walter M. Miller, Jr. A Canticle for Leibowitz 1959 J. B. Lippincott $4.95 Milton Glaser Image
1961 Walter M. Miller, Jr. A Canticle for Leibowitz 1960 J. B. Lippincott $4.95 George Sottung Image
1962 Robert A. Heinlein Stranger in a Strange Land 1961 G. P. Putnam's Sons $4.50 Ben Feder Image
1962 Robert A. Heinlein Stranger in a Strange Land 1961 G. P. Putnam's Sons / SFBC $1.70 Ben Feder Image
1963 Philip K. Dick The Man in the High Castle 1962 G. P. Putnam's Sons $3.95 Robert Galster Image
1963 Philip K. Dick The Man in the High Castle 1962 G. P. Putnam's Sons / SFBC $1.20 Robert Galster Image
1964 Clifford D. Simak Way Station^Here Gather the Stars 1963 Doubleday $3.50 Ronald Fratell Image
1964 Clifford D. Simak Way Station^Here Gather the Stars 1963 Doubleday / SFBC $1.20 Ronald Fratell Image
1965 Fritz Leiber The Wanderer 1964 Ballantine Books $0.75 Bob Abbett Image
1966 Frank Herbert Dune 1965 Chilton $5.95 John Schoenherr Image
1967 Robert A. Heinlein The Moon is a Harsh Mistress 1966 G. P. Putnam's Sons $5.95 Irv Docktor Image
1968 Roger Zelazny Lord of Light 1967 Doubleday $4.95 Howard Bernstein Image
1969 John Brunner Stand on Zanzibar 1968 Doubleday $6.95 S. A. Summit, Inc. Image
1970 Ursula K. Le Guin The Left Hand of Darkness 1969 Ace Books $0.95 Diane Dillon + Leo Dillon Image
1970 Ursula K. Le Guin The Left Hand of Darkness 1969 Walker & Co. $4.95 Jack Gaughan Image
1970 Ursula K. Le Guin The Left Hand of Darkness 1969 Walker & Co. / SFBC $1.98 Jack Gaughan Image
1971 Larry Niven Ringworld 1970 Ballantine Books $0.95 Dean Ellis Image
1972 Philip José Farmer To Your Scattered Bodies Go 1971 G. P. Putnam's Sons $4.95 Ira Cohen Image
1972 Philip José Farmer To Your Scattered Bodies Go 1971 Berkley Medallion $0.75 Richard Powers Image
1973 Isaac Asimov The Gods Themselves 1972 Doubleday $5.95 David November Image
1973 Isaac Asimov The Gods Themselves 1972 Doubleday & Company / SFBC $1.98 David November Image
1974 Arthur C. Clarke Rendezvous With Rama 1973 Harcourt Brace Jovanovich $6.95 Hal Siegel Image
1974 Arthur C. Clarke Rendezvous With Rama 1973 Harcourt Brace Jovanovich / SFBC $1.49 Hal Siegel Image
1975 Ursula K. Le Guin The Dispossessed 1974 Harper & Row $7.95 Fred Winkowski Image
1975 Ursula K. Le Guin The Dispossessed 1974 Harper & Row / SFBC $2.49 Fred Winkowski Image
1976 Joe Haldeman The Forever War 1975 St. Martin's Press $7.95 UNKNOWN Image
1977 Kate Wilhelm Where Late the Sweet Birds Sang 1976 Harper & Row $7.95 M. C. Escher Image
1977 Kate Wilhelm Where Late the Sweet Birds Sang 1976 Harper & Row / SFBC $1.98 M. C. Escher Image
1978 Frederik Pohl Gateway 1977 St. Martin's Press $8.95 Boris Vallejo Image
1978 Frederik Pohl Gateway 1977 St. Martin's Press / SFBC $2.49 Boris Vallejo Image
1979 Vonda N. McIntyre Dreamsnake 1978 Houghton Mifflin $8.95 Stephen Alexander Image
1979 Vonda N. McIntyre Dreamsnake 1978 Houghton Mifflin / SFBC $2.98 Stephen Alexander Image
1980 Arthur C. Clarke The Fountains of Paradise 1979 Harcourt Brace Jovanovich $10.00 Paul Bacon Image
1980 Arthur C. Clarke The Fountains of Paradise 1979 Harcourt Brace Jovanovich / SFBC $3.50 Paul Bacon Image
1981 Joan D. Vinge The Snow Queen 1980 The Dial Press $10.95 Leo Dillon + Diane Dillon Image
1981 Joan D. Vinge The Snow Queen 1980 The Dial Press $10.95 Leo Dillon + Diane Dillon Image
1981 Joan D. Vinge The Snow Queen 1980 The Dial Press / SFBC $4.50 Leo Dillon + Diane Dillon Image
1982 C. J. Cherryh Downbelow Station 1981 DAW Books $2.75 David B. Mattingly Image
1982 C. J. Cherryh Downbelow Station 1981 DAW Books / SFBC $4.50 Rego Image
1983 Isaac Asimov Foundation's Edge 1982 Doubleday & Company $14.95 Joe Caroff Image
1983 Isaac Asimov Foundation's Edge 1982 Whispers Press $50.00 UNKNOWN Image
1983 Isaac Asimov Foundation's Edge 1982 Doubleday $14.95 Joe Caroff Image
1983 Isaac Asimov Foundation's Edge 1982 Doubleday $14.95 Joe Caroff Image
1984 David Brin Startide Rising 1983 Bantam Books $3.50 Jim Burns Image
1985 William Gibson Neuromancer 1984 Ace Books $2.95 James Warhola Image
1985 William Gibson Neuromancer 1984 Ace Books $2.95 James Warhola None
1986 Orson Scott Card Ender's Game 1985 Tor $13.95 John Harris Image
1987 Orson Scott Card Speaker for the Dead 1986 Tor $15.95 John Harris Image
1987 Orson Scott Card Speaker for the Dead 1986 Nelson Doubleday / SFBC $7.98 Vincent Di Fate Image
1988 David Brin The Uplift War 1987 Phantasia Press $22.00 Wayne D. Barlowe Image
1988 David Brin The Uplift War 1987 Phantasia Press $60.00 Wayne D. Barlowe Image
1988 David Brin The Uplift War 1987 Bantam Spectra $4.50 Michael Whelan Image
1988 David Brin The Uplift War 1987 Nelson Doubleday / SFBC $9.98 Richard Powers Image
1989 C. J. Cherryh Cyteen 1988 Warner Books $18.95 Don Maitz Image
1989 C. J. Cherryh Cyteen 1988 Warner Books / SFBC $9.98 Don Maitz Image
1990 Dan Simmons Hyperion 1989 Doubleday Foundation $18.95 Gary Ruddell Image
1990 Dan Simmons Hyperion 1989 Doubleday Foundation $8.95 Gary Ruddell Image
1991 Lois McMaster Bujold The Vor Game 1990 Baen Books $4.50 Tom Kidd Image
1991 Lois McMaster Bujold The Vor Game 1990 The Easton Press $45.00 UNKNOWN Image
1991 Lois McMaster Bujold The Vor Game 1990 GuildAmerica Books / SFBC $9.98 Dean Morrissey Image
1992 Lois McMaster Bujold Barrayar 1991 Baen Books $4.99 Stephen Hickman Image
1993 Vernor Vinge A Fire Upon the Deep 1992 Tor $21.95 Boris Vallejo Image
1993 Vernor Vinge A Fire Upon the Deep 1992 Tor / SFBC $10.98 Boris Vallejo Image
1993 Connie Willis Doomsday Book 1992 Bantam Spectra $22.00 Tim Jacobus Image
1993 Connie Willis Doomsday Book 1992 Bantam Spectra $10.00 Tim Jacobus Image
1993 Connie Willis Doomsday Book 1992 Bantam Spectra / SFBC $12.98 Tim Jacobus Image
1995 Lois McMaster Bujold Mirror Dance 1994 Baen $21.00 Gary Ruddell Image
1995 Lois McMaster Bujold Mirror Dance 1994 Baen / SFBC $9.98 Gary Ruddell Image
1996 Neal Stephenson The Diamond Age 1995 Bantam Spectra $22.95 Bruce Jensen Image
1996 Neal Stephenson The Diamond Age 1995 Bantam Spectra / SFBC $8.98 Bruce Jensen Image
1997 Kim Stanley Robinson Blue Mars 1996 Bantam Spectra $22.95 Don Dixon Image
1997 Kim Stanley Robinson Blue Mars 1996 Bantam Spectra / SFBC $10.98 Don Dixon Image
1998 Joe Haldeman Forever Peace 1997 Ace Books $21.95 Bruce Jensen Image
1999 Connie Willis To Say Nothing of the Dog 1998 Bantam Spectra $23.95 Eric Dinyer Image
1999 Connie Willis To Say Nothing of the Dog 1998 Bantam Spectra / SFBC $11.98 Eric Dinyer Image
1999 Connie Willis To Say Nothing of the Dog 1998 Bantam Books $6.50 Eric Dinyer Image
2000 Vernor Vinge A Deepness in the Sky 1999 Tor $27.95 Bob Eggleton Image
2000 Vernor Vinge A Deepness in the Sky 1999 Tor / SFBC $13.98 Bob Eggleton Image
2001 J. K. Rowling Harry Potter and the Goblet of Fire 2000 Arthur A. Levine Books $25.95 Mary GrandPré Image
2001 J. K. Rowling Harry Potter and the Goblet of Fire 2000 Scholastic $25.95 Mary GrandPré Image
2001 J. K. Rowling Harry Potter and the Goblet of Fire 2000 Scholastic / SFBC $12.98 Mary GrandPré Image
2002 Neil Gaiman American Gods 2001 William Morrow / HarperCollins $26.00 Kamil Vojnar Image
2002 Neil Gaiman American Gods 2001 William Morrow / HarperCollins / SFBC $12.98 Kamil Vojnar None
2003 Robert J. Sawyer Hominids 2002 Tor $25.95 Donato Image
2004 Lois McMaster Bujold Paladin of Souls 2003 PerfectBound / HarperCollins $11.99 UNKNOWN None
2004 Lois McMaster Bujold Paladin of Souls 2003 Eos / HarperCollins $24.95 David Bowers Image
2004 Lois McMaster Bujold Paladin of Souls 2003 Eos / HarperCollins / SFBC $12.99 David Bowers Image
2005 Susanna Clarke Jonathan Strange & Mr. Norrell 2004 Bloomsbury USA $27.95 Portia Rosenberg + William Webb Image
2005 Susanna Clarke Jonathan Strange & Mr. Norrell 2004 Bloomsbury USA $27.95 Portia Rosenberg + William Webb Image
2005 Susanna Clarke Jonathan Strange & Mr. Norrell 2004 Bloomsbury USA / SFBC $14.99 UNKNOWN None
2005 Susanna Clarke Jonathan Strange & Mr. Norrell 2004 Bloomsbury USA $27.95 Portia Rosenberg + William Webb Image
2006 Robert Charles Wilson Spin 2005 Tor $25.95 Drive Communications Image
2006 Robert Charles Wilson Spin 2005 Tor / SFBC $12.99 Drive Communications Image
2007 Vernor Vinge Rainbows End 2006 Tor $25.95 Stephan Martiniere Image
2007 Vernor Vinge Rainbows End 2006 Tor / SFBC $13.99 Stephan Martiniere Image
2008 Michael Chabon The Yiddish Policemen's Union 2007 HarperCollins $26.95 Will Staehle Image
2008 Michael Chabon The Yiddish Policemen's Union 2007 HarperCollins $26.95 Will Staehle Image
2008 Michael Chabon The Yiddish Policemen's Union 2007 HarperAudio $39.95 Will Staehle Image
2008 Michael Chabon The Yiddish Policemen's Union 2007 HarperLuxe $26.95 Will Staehle Image
2008 Michael Chabon The Yiddish Policemen's Union 2007 HarperCollins / SFBC $14.99 Will Staehle Image
2009 Neil Gaiman The Graveyard Book 2008 HarperAudio $18.99 Dave McKean Image
2009 Neil Gaiman The Graveyard Book 2008 HarperCollins $17.99 Dave McKean Image
2009 Neil Gaiman The Graveyard Book 2008 Harper Children's Audio $22.95 Dave McKean Image
2009 Neil Gaiman The Graveyard Book 2008 HarperCollins $18.89 Dave McKean Image
2009 Neil Gaiman The Graveyard Book 2008 HarperCollins / SFBC $11.99 Dave McKean Image
2010 China Miéville The City & The City 2009 Del Rey / Ballantine $26.00 FWIS Image
2010 China Miéville The City & The City 2009 Del Rey / Ballantine $11.99 UNKNOWN Image
2010 China Miéville The City & The City 2009 Del Rey / Ballantine $26.00 FWIS Image
2010 China Miéville The City & The City 2009 Del Rey / Ballantine / SFBC $14.99 FWIS Image
2010 China Miéville The City & The City 2009 Subterranean Press $75.00 Vincent Chong Image
2010 Paolo Bacigalupi The Windup Girl 2009 Night Shade Books $24.95 Raphael Lacoste Image
2010 Paolo Bacigalupi The Windup Girl 2009 Night Shade Books $6.00 Raphael Lacoste None
2010 Paolo Bacigalupi The Windup Girl 2009 Night Shade Books $15.99 UNKNOWN Image
2011 Connie Willis Blackout 2010 Spectra / Ballantine Books $11.99 UNKNOWN Image
2011 Connie Willis Blackout 2010 Spectra / Ballantine Books $26.00 Charles Brock Image
2011 Connie Willis Blackout 2010 Spectra / Ballantine Books / SFBC $14.99 Charles Brock Image
2011 Connie Willis Blackout 2010 Subterranean Press $75.00 J. K. Potter Image
2011 Connie Willis Blackout 2010 Spectra / Ballantine Books $26.00 Charles Brock Image
2011 Connie Willis Blackout 2010 Spectra / Ballantine Books $16.00 UNKNOWN Image
2011 Connie Willis Blackout 2010 Brilliance Audio $39.99 UNKNOWN Image
2011 Connie Willis Blackout 2010 Brilliance Audio $29.99 UNKNOWN Image
2011 Connie Willis All Clear 2010 Spectra / Ballantine Books $26.00 Charles Brock Image
2011 Connie Willis All Clear 2010 Spectra / Ballantine Books / SFBC $15.99 Charles Brock Image
2011 Connie Willis All Clear 2010 Spectra / Ballantine Books $11.99 UNKNOWN Image
2011 Connie Willis All Clear 2010 Brilliance Audio $39.99 UNKNOWN Image
2012 Jo Walton Among Others 2011 Tor $24.99 Kamil Vojnar Image
2012 Jo Walton Among Others 2011 Tor $9.99 Kamil Vojnar Image
2013 John Scalzi Redshirts 2012 Tor $24.99 Peter Lutjen Image
2013 John Scalzi Redshirts 2012 Tor / SFBC $14.99 Peter Lutjen Image
2013 John Scalzi Redshirts 2012 Tor $9.99 Peter Lutjen Image
2014 Ann Leckie Ancillary Justice 2013 Orbit (US) $15.00 John Harris Image
2014 Ann Leckie Ancillary Justice 2013 Orbit (US) $9.99 UNKNOWN Image
2015 Cixin Liu The Three-Body Problem 2014 Tor $25.99 Stephan Martiniere Image
2015 Cixin Liu The Three-Body Problem 2014 Tor / SFBC $26.99 Stephen Martiniere Image
2016 N. K. Jemisin The Fifth Season 2015 Orbit (US) $15.99 Lauren Panepinto Image
2016 N. K. Jemisin The Fifth Season 2015 Orbit (US) $9.99 UNKNOWN Image
2017 N. K. Jemisin The Obelisk Gate 2016 Orbit (US) $15.99 Lauren Panepinto + Arcangel Image
2017 N. K. Jemisin The Obelisk Gate 2016 Orbit (US) $9.99 UNKNOWN Image
2018 N. K. Jemisin The Stone Sky 2017 Orbit (US) $16.99 Lauren Panepinto + Arcangel Images Image
2018 N. K. Jemisin The Stone Sky 2017 Orbit (US) $11.99 Lauren Panepinto + Arcangel Images Image
2018 N. K. Jemisin The Stone Sky 2017 Orbit (US) $16.99 Lauren Panepinto + Arcangel Images Image
2019 Mary Robinette Kowal The Calculating Stars 2018 Tor $18.99 Jamie Stafford-Hill Image
2019 Mary Robinette Kowal The Calculating Stars 2018 Tor $9.99 UNKNOWN Image
Thanks, I'll let James know! Ahasuerus 22:25, 16 September 2019 (EDT)

Sciencewood - non-genre non-fiction - a second set of eyes needed

Does anyone see a reason to keep this one in the DB? It looks like a popular science book, no speculative element and not about speculative content -- which is out of scope if you are not above threshold. Or is there something I am missing about the author or the book? Thanks to anyone that would lend an eye (or 2) to that book and help determine what to do with it. Annie 18:00, 17 September 2019 (EDT)

Not seeing anything that would indicate it belongs here. The author image is from Amazon, so we won't need to remove it if the book is deleted (since this is the only entry for the person). ···日本穣 · 投稿 · Talk to Nihonjoe 18:36, 17 September 2019 (EDT)
And it had been nuked from space - both pub and title. Even if we had to delete the image manually, it is not that hard either. Thanks for verifying for me. :) For anyone interested who lands here after the deletion, this is the book in question. Annie 18:51, 17 September 2019 (EDT)

Curious records in awards table for Tiptree Award

The records in the awards table for the Tiptree have (at least) 8 "meta" records that seem to be purely for display purposes, and aren't actually works that were nominated for the award. This SQL query will show them (at least the ones I'm aware of): 

   select * from awards where award_title  like '%Honor List%' or award_title like '%Long List%';

Alternatively, you can see them at these URLs:

I've not noticed these for any other award, and they only seem to exist for 2009, 2011, 2013, 2014 and 2015 in the Tiptree. (I noticed them a while ago, but it's only now that I need to deal with them for a project I'm working on that uses a local copy of the database.)

Are these a legitimate/expected way of using ISFDB? If not, could/should they be deleted?

As far as I can tell they have use award_level values - as opposed to some special value that might indicate they are meta-records - which were chosen so that they appear in a particular place on the award pages (such as the first of the three links above). However, they seem somewhat redundant functionally, as the "proper" Finalists and Honorable Mentions headings also appear on that page. Perhaps someone felt those terms were inaccurate, and created these other records to try to address that? —The preceding unsigned comment was added by ErsatzCulture (talk • contribs) .

I am not sure I am getting the question - so let me try to clarify :)
The Honorable list is an official list and we do record Long lists and so on when an award announces them - so their availability depends on the award itself. So what exactly is bothering you? Annie 19:08, 18 September 2019 (EDT)
If you look at the 45437 & 45438 links provided above, you will see that the "--- Honor List ---" and the "--- Long List ---" headings on the year page have been implemented by creating fake award records. It's a rather unorthodox attempt to add the award's actual names for these subcategories instead of the ISFDB's standard award levels. -- JLaTondre (talk) 19:18, 18 September 2019 (EDT)
(JLaTondre has basically given my response - much more succinctly - but here's what I was about to submit before getting into an edit conflict):
My question isn't with the awarded works being in the database, but that there are additional records - the ones with these headings - that have also been added, which don't exist for any other awards, or indeed for most years for the Tiptree. This makes writing code that queries the database a bit of a hassle - not impossible to deal with, but more than I'd like, especially if the offending records shouldn't have been there to start with.
Let me give an example. If I wanted to know how many finalists there were in 2018 - a year which isn't affected by this issue - I would do this database query:
   select count(1) from awards where award_type_id = 43 and award_cat_id = 523 and year(award_year) = 2018 and award_level = 90;
and get back the answer 11, which is correct. (Just for clarify: 43 and 523 are the IDs for the Tiptree and its main category respectively; 90 denotes finalist.)
If I switch the year value to 2015, and run the query, I get back 12. That's one too many, because "--- Honor List ---" is counted as one of the finalists. To get the right answer, I would have to add some logic to filter these out, but that requires foreknowledge of what these "meta-values" are, and for all I know, next year someone could enter them with different text, or as italic, and then my code will be wrong again.
Don't get me wrong - I'm certainly not asking or expecting ISFDB to change functionality just to suit my personal project, but my suspicion is that perhaps these "meta-records" weren't something that was expected when the award functionality was designed or implemented.
Can I ask a question in turn - is there any particular reason you know of why 2009, 2011, 2013, 2014 and 2015 might have these records, but no other years of the Tiptree? —The preceding unsigned comment was added by ErsatzCulture (talk • contribs) . 16:30, 18 September 2019 (EDT)
It looks like someone was wanting it to say "Honor List" and "Long List" instead of the system-generated "Finalists" and "Honorable Mentions" (respectively), even though these last two are still displayed. So, pretty much what JLaTondre wrote. I think these should be removed. ···日本穣 · 投稿 · Talk to Nihonjoe 19:35, 18 September 2019 (EDT)
(after resolving conflict) Ah, now that you pointed it out, I see it - I was loking at the lists themselves and not getting it. :) Sorry - had a slow moment here :) Isn't that similar to a question we had earlier this month about special names and what's not (wasn't it one of the Japanese awards?) - except someone went and did them that way instead of asking how? I would say that they should be removed and we need to discuss that "custom naming" thing for awards and levels.
As for why only some years - because noone added them? :) Different people add different awards at different times so... who knows - we keep adding missing information all over the place. Annie 19:37, 18 September 2019 (EDT)
I've deleted the bogus records. ···日本穣 · 投稿 · Talk to Nihonjoe 19:41, 18 September 2019 (EDT)
Thanks. —The preceding unsigned comment was added by ErsatzCulture (talk • contribs) . 16:47, 18 September 2019 (EDT)

eBook types

Hello all. Recently I re-visited this ebook pub record, to which an ASIN was added well after I created the record. Since this ASIN is for another ebook format (MOBI/AZW) compared to the original (EPUB), it started me thinking if we need/want to discriminate between different ebook formats, much like we have hc, tp, pb,... format types for paper books? Searching the internet a bit reveals that this particular pub, when bought from bol.com, is in EPUB format, whereas if it is bought from Amazon it will likely be in AZW3 (MOBI for older books I believe - not 100% sure on this one) format. So, since these are different formats, and since they generally are DRM protected and therefore not readily convertible into one another (at least not officially, that is...), I'd think it makes sense to add ebook formats to the dropdown list. Could be something like

  • ebook - EPUB
  • ebook - MOBI
  • ebook - AZW (all versions)
  • ebook - IBA (this one's Apple's, I believe)
  • ebook - other

as these are the most popular ones.
Thoughts ?
BTW, nice summary here: https://www.makeuseof.com/tag/ebook-formats-explained/
MagicUnk 09:04, 19 September 2019 (EDT)

A lot of books are available in multiple formats at the same time -- do we really want to add multiple copies to the DB? And unlike the physical books, conversions are possible very easily. I would much prefer we keep one type and either use Notes or add a new text field for format details... Just thinking aloud. Annie 10:33, 19 September 2019 (EDT)
I guess that if it would be so that electronic versions could be easily and without any restrictions and at all times be converted into each other (or be able to be read by whatever reading app/device), we could argue that the issue is moot and that for all practical intents and purposes the ebook formats can be effectively considered the 'same' (for as far as we're talking about the exact same contents of course). However, since this is not the case (not all formats can (should legally not) be converted, nor all ereaders can read all formats), I am inclined to think we should be able to make a distinction - preferably without having to clutter the notes, but if not, then the notes will have to do :).
Now, as for the how to distinguish, I see a couple of options. Adding more choices to the dropdown as listed above is just one possibility, and would be in line with what we already have for paper and even for audio formats too, albeit that these are physical formats, as opposed to electronic ones for ebooks. Adding an additional field to select the ebook (sub-)type is another, and even adding multiple additional types to a single ebook pub record (much like the possiblity to add multiple external ID's with the '+' button, or what we intend for the eagerly awaited multiple price enhancement - hint-hint :), could be a third. MagicUnk 11:23, 19 September 2019 (EDT)
I think we should handle this at the publication level as we always have. A publication is a salable product (and can and often is assigned an ISBN, UPC or other product code). Does one have to buy the item again to get another format? Then it likely is a separate publication. If not, then it is more like another part of the same product/publication (and we do not explicitly track that though a note in the pub record stating which formats a publication supports might be nice). Uzume 11:51, 22 September 2019 (EDT)
Well, that's the thing, isn't it? You cannot normally convert/are not allowed to convert between EPUB and MOBI, so you'd have to buy a new version, hence end up with two pub records... MagicUnk 18:42, 23 September 2019 (EDT)
It is quite easy to convert between the two. There are sellers who also provide multiple formats for a single purchase. This suggestions adds a lot of complexity & work for no gain. -- JLaTondre (talk) 18:50, 23 September 2019 (EDT)
I am not aware that it is legal to do so in all cases, or is it?MagicUnk 01:57, 24 September 2019 (EDT)
As long as one does not sell the converted copy I believe this is legal under fair use. Uzume 00:25, 1 October 2019 (EDT)

Multiformat magazines and series grids

We have two separate ways to record magazines that publish their issues in more than one format (print + ebook for example or webzine + print + ebook).

  • Two separate series - 1 per format. This becomes a problem if one of the format is discontinued - someone needs to know to look for the other series. And if one of the two formats does not exist from the beginning, it looks incomplete. Plus the series are almost never kept in parallel (example and its digital brother.
  • One series, all formats merged into a single early record. This can make the grid look heavy (and repetitious) but gives the full picture of the magazine. example.

Which one is used depends on the editor who sets the series basically - so we have both all over the place (and sometimes the wrong formats end up in the wrong place when someone does not pay attention). It is probably a good idea to at least try to decide what the standard should be. :)

I prefer the second way (we can always add some filters on the grid page if they start looking heavy) - especially now that we show the non-common formats so it will be clear why we have multiples. What does everyone think? Annie 23:14, 19 September 2019 (EDT)

Magazine handling is a little strange. It would be easier from a data management/maintenance perspective if we put it all into one. I wonder if we could somehow use a combination of pub series and title series to help organize. --MartyD 07:39, 20 September 2019 (EDT)
I believe we still support super series, e.g. you can see Astounding / Analog (1937-1971) and Astounding/Analog (UK), however there is also Astounding/Analog which merges the two (albeit in this case with some other stuff but methinks you get the idea). Also in this case the UK reprints are not exactly exposing a different format so much but a super series could be made for both of Galaxy's Edge and Galaxy's Edge (digital edition) and then one would be able to view a merged issue grid if one wanted to. For something like Journey Planet, one would have to split the editorial records and make another series and then super series the both. Uzume 11:23, 22 September 2019 (EDT)
Since Marty brought it up again, I always thought magazines should be defined/handled as pub series instead of the hackish way we do it now using their editorial records (which I have never suggested should go away; for some reason whenever I mention magazines as pub series that is the first thing people seem to think I am trying to get rid of). I realize we have many such records and it would be a large effort to create pub series for all the magazines/fanzines, etc. but it does solve the complexity of our current issue grid (and having an issue grid view for other non-magazine pub series might be useful too; I wonder if we have an FR on that) as well as allowing us to merge editorial records for different formats/reprints/etc. but still allow one to record and present them each separately. I believe our software does not currently support super pub series (though that might also be a useful addition) Uzume 11:23, 22 September 2019 (EDT)

Biographical warnings for audio books

I think that awhile back we suspended showing bibliographic warnings for missing ISBN/Catalog ID when the format of the book is ebook. Can we extend that to the "digital audio download" type as well? Example where we have both types and just one warning: Yarn. Or is there a reason to always have it (because these will (almost) never have ISBNs and catalog numbers)? Thanks! Annie 04:02, 21 September 2019 (EDT)

I don't think it was a conscious decision. We (or at least I) didn't realize that "digital audio download" books typically didn't have ISBNs. Ahasuerus 09:12, 21 September 2019 (EDT)
I think it was a "let's try to clean this thing" kind of thing and as we did not have that many audio books, noone thought of it.:)
How about prices and webzines? The warning is there even though the vast majority of webzines do not have prices unless we really like typing 0.00. And since we opened the doors for them, we have more than we used to. Annie 11:51, 21 September 2019 (EDT)
FR 1306, "Suppress bibliographic warnings for digital audio downloads", has been created. Ahasuerus 10:55, 3 October 2019 (EDT)
FR 1306 has been implemented. Ahasuerus 15:36, 4 October 2019 (EDT)
Any objections to suppressing bibliographic warnings for webzine issues without a price? Ahasuerus 10:55, 3 October 2019 (EDT)
Hearing no objection, FR 1308 has been created. Ahasuerus 21:32, 10 October 2019 (EDT)
FR 1308 has been implemented. Ahasuerus 19:16, 12 October 2019 (EDT)

Question about the Twilight Zone Universe lists

Is there a reason for not including Richard Matheson's Twilight Zone Scripts volumes in the Twilight Zone Universe lists? —The preceding unsigned comment was added by Klepsis (talk • contribs) .

Good catch! I have put them in a new series, Twilight Zone Scripts (Richard Matheson), and turned it into a sub-series of Twilight Zone Universe. I've also disambiguated the name of Twilight Zone Scripts (Rod Serling) to avoid confusion. Thanks! Ahasuerus 18:46, 3 October 2019 (EDT)

Templates for incomplete contents

Can we create a template for incomplete contents to be used in publication Notes ({{Incomplete}} for example) that shows "The contents are incomplete" (or anything else we want for it to say)? We have a very good way to find magazines and collections and anthologies with no fiction content but once at least one story is added, the title drops from the report (and sometimes a non-fiction magazine that is ignored from the report still needs its no-fiction contents to be finished. And every editor seems to use their own string: "Content from Place; possibly incomplete.", "Incomplete Contents", "contents incomplete", "contents possibly incomplete" and so on. Trying to find all of them so someone can update them is... hard. Annie 16:30, 3 October 2019 (EDT)

Seems like a good idea. Can anyone think of a reason not to create {{Incomplete}}? Ahasuerus 11:30, 4 October 2019 (EDT)
FR 1309, "Create an 'Incomplete' template", has been created. However, before I do implement it, let's make sure that we are all on the same page. The use of this template is supposed to be limited to pubs missing eligible Contents items; it will not be used for pubs which exclude ineligible (typically non-genre) items on purpose, right? Ahasuerus 21:38, 10 October 2019 (EDT)
Yeah, that's the idea. Christian Stonecreek 02:49, 11 October 2019 (EDT)
Yep. Annie 03:12, 11 October 2019 (EDT)
The FR has been updated. Thanks! Ahasuerus 15:16, 12 October 2019 (EDT)

Leading and Trailing spaces in External IDs

Can we modify the javascript check when submitting a publication to first trim() the data in the field and then check if it contains any of the characters we do not want (and then trim again on the back end before saving so we do not save them or pass back the trimmed value)? If I leave an extra space at the end of a title, ISBN or any other field, it just ignores it and cleans it up before saving. The External ID field makes me go and remove it before I can submit... :) Thanks! Annie 20:29, 3 October 2019 (EDT)

Makes sense. FR 1307, "Strip leading and trailing spaces in External IDs", has been created. Ahasuerus 12:12, 4 October 2019 (EDT)

New User

Greetings from Algonquin

I am a very new user to your App (isfdb.org).

What is the purpose of isfdb.org?

With Best Regards,

Jed Dowd (Algonquin) Mypoustinia@msn.com 3 October 2019 at 20:33 CDT —The preceding unsigned comment was added by Algonquin (talk • contribs) .

Welcome to the Database. We are a bibliography site - trying to cover the field of Speculative fiction and list all editions of all books published in the field (and it is a work in progress...). Look around - if you want you can just browse and use the data or you can decide to help - if so, here is the main wiki page with a lot of useful links on how to do things and what you can do and so on :) And you can always ask here.
From our main page: "The ISFDB is a community effort to catalog works of science fiction, fantasy, and horror. It links together various types of bibliographic data: author bibliographies, publication bibliographies, award listings, magazine content listings, anthology and collection content listings, and forthcoming books.".
How did you find us and what were you looking for? :) Annie 22:02, 3 October 2019 (EDT)

Add the rest of the Amazons where they are missing

Can we add the rest of the Amazons to the list of available sites for links? We have only 6 of them now (including missing one of the English language ones...)- and I keep needing some of the rest and having the direct link there will be very useful...

And just in case the list is stored separately, I also want them on the moderator screen so I can click on them for books with ISBNs while trying to research a submission.

And while we are at it, we are also missing two Amazons on the ASIN list - Turkey and UAE:) Annie 00:32, 4 October 2019 (EDT)

Sure, we can do that. Our list of supported Amazon stores hasn't been adjusted in years. A lot has changed in the last decade. Here are the stores that we currently support:
  • Amazon CA
  • Amazon DE
  • Amazon FR
  • Amazon JP
  • Amazon UK
  • Amazon US
Here are the Amazon stores that I think we could add:
Any others? Ahasuerus 11:59, 4 October 2019 (EDT)
You should have 16 - so one is missing: Netherlands. And it is one I need a lot - we have quite a lot of Dutch speaking editors these days:) Annie 12:07, 4 October 2019 (EDT)
Noted, thanks. Ahasuerus 12:15, 4 October 2019 (EDT)

(unindent) One problem that I think we are going to have is "screen real estate". Once we link all 16 Amazon stores, the "Other Sites" drop-down list on the Publication display page is going to become unwieldy. Perhaps we could move the Amazon links (all 16 of them) to another, adjacent, drop-down list? I guess we could call it something clever like "Amazon Links". Ahasuerus 22:39, 10 October 2019 (EDT)

Yes, this seems to be a better solution. Christian Stonecreek 02:48, 11 October 2019 (EDT)
Thanks. FR 1310, "Link to all Amazon stores", has been created. Ahasuerus 15:15, 12 October 2019 (EDT)

Series content counts

How easy would it be to have the system do a count every day (or every week) of the number of unique titles in a series, then list those numbers at the top of the series page? Maybe even list the number of short fiction, collections, omnibuses, non-fiction, etc., too? This might be useful information on author/artist pages, too. ···日本穣 · 投稿 · Talk to Nihonjoe 13:27, 4 October 2019 (EDT)

I assume you mean mostly for series that are not numbered, right? I like the idea. :) Annie 13:32, 4 October 2019 (EDT)
It's more for series that are ginormous (like Star Wars or Star Trek), that have a bunch of different series within the series, as well as many collections, omnibuses, short fiction, and so on. Statistics are harder to manually do in those cases. ···日本穣 · 投稿 · Talk to Nihonjoe 13:58, 4 October 2019 (EDT)
I like the idea of displaying counts. Not just for series, but for the Contents sections of publication pages as well. However, I don't think we want to calculate them once a day/week because it would create discrepancies. Doing it on the fly shouldn't really affect performance.
The only problem that I can see is the way the software currently displays embedded series. It would likely require a medium amount of work to get everything working properly. Ahasuerus 15:03, 4 October 2019 (EDT)
I imagine there's a series table in the database, listing the title and parent for each series. If a new column (or columns, depending on how granular you want to do things) was added to each series for the count, then it would be a run through to do all the counts, then another that adds up counts for any subseries. The last one would repeat until all the sub-sub-sub-sub series are totaled. Something like that? ···日本穣 · 投稿 · Talk to Nihonjoe 15:15, 4 October 2019 (EDT)
True, there is a "series" table in the database. It contains each series':
  • title
  • parent series
  • relative position within its parent series
  • note
That said, adding a new column and updating it on a daily/weekly basis would result in series counts being potentially out of sync with what is actually displayed for up to 24/168 hours. I believe that would be Very Bad (tm).
Now, the problem with doing these calculations on the fly is that the software which displays series data is invoked recursively for embedded sub-series. Every time it is called, it doesn't know much about the parent series that invoked it; it just displays all titles in the series and returns to its parent, which then calls it again to display the next sub-series, etc. The software would need to be modified to keep track of the total number of titles that it has displayed for the whole series tree. In addition, it wouldn't have the totals until the last sub-series has been displayed, so it would have to be displayed at the bottom of the page -- unless we redesigned the software to accumulate all that display data first and display it second. To complicate matters, the same series display code is used by Series pages as well as by Author Bibliography pages. They display co-authors differently.
In other words, it's probably doable, but would require a certain amount of tinkering. Ahasuerus 15:51, 4 October 2019 (EDT)
How about a solution similar to how we solved the counts number in Advanced Search? Instead of showing it every time, add a button/link which calculates it and shows it on the fly when pressed? This way an editor can find the number easily but we do not calculate it for series that do not need it and we do not change all the underlying logic of the series pages. Annie 16:00, 4 October 2019 (EDT)
Another possibility: Have the count on each series update whenever a new item is added to the series? That would keep it current, and be a logical place for it to increment the count. Then, when it's incremented the count, have a subroutine that checks to see if the series has a parent. If so, then have it increment the parent's total count. Do that until there are no more parents. There would have to be something in place to prevent simultaneous incrementing (in case two or more different entries were updated/approved simultaneously), so it would do one, and then the other. When initially implemented, a single-run script could create the initial counts for each series, and then the updating could be done as I described above. ···日本穣 · 投稿 · Talk to Nihonjoe 16:03, 4 October 2019 (EDT)
This strikes me as a cool idea, but the developer part of my brain wonders about all the nasty edge cases. e.g. would it make sense to show The Night's Dawn *Trilogy* as comprising 9 novels - the 3 UK (?) volumes plus the 6 volumes from the "Night's Dawn Trilogy (paperback)" subseries, which are (AFAIK) the same content, just split into 2 smaller books? From my limited understanding of the database, I don't see anything that indicates the latter are a "variant series", other than text notes in the former stating that they were split into 2 volumes for US publication. ErsatzCulture 17:40, 4 October 2019 (EDT)
And you also have the moving of series under new parents (or removing them from parents) which will cascade calculations at update time as both the new and the old parent and the current series totals (plus all additional parents) will need to be recalculated... Annie 17:49, 4 October 2019 (EDT)
True. As a general observation, database designs that required keeping running totals of things were popular in the 1960s and 1970s, back when data was mostly stored on tape. They became less popular once cheap and reliable disk storage became available. And a good thing too because they were a pain to maintain. Ahasuerus 19:57, 4 October 2019 (EDT)

New cleanup report - Publication Series Names That May Need Disambiguation

A new cleanup report, "Publication Series Names That May Need Disambiguation", has been coded and deployed. The data will become available overnight. I expect approximately 75 records to be flagged. Ahasuerus 21:57, 4 October 2019 (EDT)

Displaying title tags on the Advanced Search Results page

Last year we had the following request posted on the Community Portal (FR 1166):

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.
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.
Alternatively, we could set a hard width for the column using a percentage. ("Specific pixels width" wouldn't work for phones.)

Earlier today User:ErsatzCulture proposed the following solution:

  • If the user included a tag value in their search criteria, show all tags (on the logic that this is something they're definitely interested in, and we don't want to risk hiding the tag they searched on)
  • If they didn't include a tag in the search criteria, then we limit the number of tags - currently 5, which seems to limit to no more than 2 lines of tags on a 1280px wide screen.
Example screengrabs:

NoTagCriteria.png

WithTagCriteria.png


I rather like this approach. What do other editors think? Ahasuerus 10:35, 7 October 2019 (EDT)

I like the approach but I still think we need to do some restriction on the field and/or the ability not to see tags at all. I do most of my work from small screens - and having 5 tags is already making my screen too hard to see what I need. And the things get worse if one of the tags is extra long. Annie 12:11, 7 October 2019 (EDT)
Seems a bit counter-intuitive. If I search for titles with a particular tag, it's likely I know everything I need to about tags for my selection. And I'm assuming my tag is there for everything displayed. Unless you get into OR conditions ... ../Doug H 14:03, 7 October 2019 (EDT)
I think you're correct on a functional level, but I think human beings generally need reassurance that the results they've got back match what they expected to get. Compare this to when you do a search for something on Google or on a Kindle device, the displayed results highlight the searched keywords in bold or inverse video to show you the match, and to provide context etc.
My thinking for displaying all tags if the user searched for tags, is that searching on tags expressly signals an interest in tagging from the user, so it seems reasonable to show detail in that area.
Re. user controllable showing/hiding of columns, this would obviously be a preferable solution, but it would involve more work. Also, it feels like something which doesn't fit the current preference model, but rather something which should be configurable on the fly in the results page itself, probably with the prefs being stored on a per-device level. (If anyone's switching between using the site on a phone and an HD/4k screen on a regular basis, it's unlikely they'd want the same display settings in both environments.)
All of this is doable, it's just working out the tradeoffs between user needs and pain (and obv. the needs etc of casual users vs contributors vs mods aren't necessarily the same), developer time/interest, etc, etc.... ErsatzCulture 14:30, 7 October 2019 (EDT)
after thinking some more on that. A bit of a background. I proposed that FR awhile ago because the current results screen makes it very hard for me to do a lot of the things I do on a daily basis. This solution won’t solve the problem so if you want to implement it, go ahead and do that. Then I will ask for another FR that actually solves the problem I am having. If you have a big enough screen, the tags are not that big of a trouble - we do not have that many titles with more than 5 tags (can someone check how many)? And the problem is not just how many lines they take but also how much of the screen they take - they squeeze (squish in my original writing above) the columns I am looking for on a small screen taking more than half the screen. And let’s not ignore the fact that a lot of the casual browsers will be using touchscreens and other small screen devices - and making that page work only when you are at home and have your nice big screen is a little behind the times. :) Annie 15:09, 7 October 2019 (EDT)
Not directly related, but it might be good to start planning for a mobile version of the site that presents the options better for a smaller screen. Maybe we should make a page to start discussing that. It would basically present information based on the reported browser. ···日本穣 · 投稿 · Talk to Nihonjoe 16:04, 7 October 2019 (EDT)
It is not just mobile though - I have one of the small Chromebooks (11.6") which is perfect for what I need it for - but the screen is small :) And when a page is optimized for regularly sized screen, it does need to compensate somewhere :) But yeah - we probably should - although some of the pages will need too much of a redesign... Annie 21:30, 7 October 2019 (EDT)
If we spend the time hammering out a good design, it will make making changes more easy in the future. I've made this page to help facilitate discussions toward that end. ···日本穣 · 投稿 · Talk to Nihonjoe 15:17, 11 October 2019 (EDT)

Signing notes

Is there a simple way to sign and date notes (Title and Publication in particular) that is invisible on the display but easily seen and edited in the Editing window? ../Doug H 11:25, 10 October 2019 (EDT)

Nope. Which is why I add a very visible date when that is relevant.
Technically you can use {{BREAK}} which will send it to a separate screen so it will be there if someone wants to see it but not there on the main screen. Annie 11:51, 10 October 2019 (EDT)
So nothing like html comments <! > or null tags ../Doug H 12:35, 10 October 2019 (EDT)
Nope. If you use them, they will get flagged as not allowed HTML and cleaned up overnight if the accepting moderator does not catch them on submit and clean them there and then. If you think they will be useful, you can always open a discussion about allowing them but... I am not a fan of hidden text - way too easy to miss and way too easy to be exploited for someone's advertisement purposes or other mischief. And if we want to keep track of the notes, we probably should built it into the system as opposed to asking an editor to add the data. Annie 13:31, 10 October 2019 (EDT)
Wouldn't it be a good thing we'd always sign & date the notes? I'm working at a pharma company, and there it's mandatory to always sign & date every single change you make to a record ... MagicUnk 09:49, 11 October 2019 (EDT)
Only if we have a system that suppresses that from the everyday screens. You really do not want 20 lines of history for every line of a note. :) Annie 13:00, 11 October 2019 (EDT)
Well, there is FR 1238, "Create an Edit History page for publications", which would create snapshots of verified publication records before they are changed. It would help with a lot of different issues. Ahasuerus 14:56, 12 October 2019 (EDT)
Won't help with Title records though. Implementing a search in the submissions list will help to at least find the history of a title (if not changed) though... Annie 15:22, 12 October 2019 (EDT)

'Incomplete' template created

"Incomplete", a new template, has been created as per FR 1309. At this time it is displayed as "Contents incomplete."

Checking the database, I see that we have:

  • 508 notes with the words "content[s] incomplete"
  • 31 notes with the words "incomplete content[s]"
  • 422 notes with the words "partial content[s]"

Should we create a cleanup report to review/update them? I assume the report will need to support the "ignore" functionality. Ahasuerus 20:02, 12 October 2019 (EDT)

I can pick these off with search but a report may be worth it for future additions. There is one more pattern “content[s] [random words] incomplete/not complete”. Annie 20:17, 12 October 2019 (EDT)
That's a good point. There are 831 matches, including 508 previously listed "content[s] incomplete" matches. Ahasuerus 20:27, 12 October 2019 (EDT)
I wonder if a wider net may be even better: If it has the word content[s] and "incomplete|partial|not complete", throw it on the report so we can sort it out and decide if it can be filled in (best solution), needs the template or is one of the non-genre stories type where it will stay like that. And then of course we will need a report for the ones that have the template - similar to the reports for the anthologies and magazines with no contents one day. Annie 20:59, 12 October 2019 (EDT)
A cleanup report is a very good idea. I've come across several records like this in the past, where it seems that the editor put the "incomplete" info into the pub's note but then forgot about it.
In addition to the already mentioned words, there are a few more words to consider which will find pubs like this and this (but also one or the other false positive, therefore an "ignore" option in the report is a good idea):
  • "%to be entered"
  • "%more%contents%added%"
  • "%not entered yet%"
  • "%have to be added%"
Jens Hitspacebar 07:47, 13 October 2019 (EDT)
Very good points. I have run a bunch of database searches to get a better idea of how many false positives some of the proposed search strings are likely to generate and created FR 1311, "Cleanup report to look for pubs with incomplete contents". Ahasuerus 12:40, 13 October 2019 (EDT)
Some other thing to consider is to ignore pubs that already have the 'incomplete' template in the notes, see eg this one. MagicUnk 14:27, 13 October 2019 (EDT)
That’s a given - we have quite a lot of reports like that already so the exclusion does not need mentioning. Annie 14:38, 13 October 2019 (EDT)
Yup, notes which include the string "{{Incomplete}}" will be skipped with extreme prejudice! Ahasuerus 16:08, 13 October 2019 (EDT)

(unindent) The new cleanup report has been deployed; the data will become available in about 6 hours. I expect that we will need to review around 1,860 pubs.

I have also created FR 1312, "Cleanup report to find pubs which use the 'Incomplete' template". Ahasuerus 19:53, 13 October 2019 (EDT)

I added information about the new template to Help:Using_Templates_and_HTML_in_Note_Fields. Please correct if I got something wrong there. Jens Hitspacebar 15:03, 14 October 2019 (EDT)
Thanks! I knew I was forgetting something... Ahasuerus 16:17, 14 October 2019 (EDT)

The listing for this non-genre publication is intentionally incomplete, only SF content is listed

We have 110 publications with this specific wording and I kinda like it a lot. How about a template ("non-genre incomplete" for example) for this? It will be useful in two ways:

  • Someone finding the publication will know why it is half-empty.
  • An approving moderator will be extra careful when approving more content.

Plus it will take less typing than the full message. :) Thoughts? Annie 03:46, 16 October 2019 (EDT)

I like this idea. ···日本穣 · 投稿 · Talk to Nihonjoe 13:06, 16 October 2019 (EDT)
Should it be "only SF content is listed" or "only ISFDB relevant works listed" (or similar wording)? That would handle the non-genre author above the the threshold issue for mixed genre anthologies. The "ISFDB relevant" could be then linked to the Rules of Acquisition policy page. -- JLaTondre (talk) 18:11, 16 October 2019 (EDT)
Probably. That's part of the beauty in using a template - we can change what it says when we want to without running yet another cleanup project. And I was thinking about adding a link as well - this was just the best way I found already recorded :) Annie 18:17, 16 October 2019 (EDT)
Like this idea. I've entered a number of "content only includes genre items" in the past, and a template would be welcome. Bob 18:44, 16 October 2019 (EDT)
I like the idea of a template, but I am still trying to come up with a name that would cover all the bases. The only thing that I am more or less sure about it that I like "eligible [for inclusion]" more than "relevant". Ahasuerus 19:18, 16 October 2019 (EDT)
Yes, "only ISFDB eligible works listed" would be better. -- JLaTondre (talk) 19:20, 16 October 2019 (EDT)
I like "ISFDB eligible" as wording of the text. How about "policy incomplete" or "DB incomplete" or something along that line for a name. It needs to be short enough and clear enough if we want adoption without too many misspellings. Annie 19:38, 16 October 2019 (EDT)
Another option would be "Only Eligible". Ahasuerus 19:52, 16 October 2019 (EDT)
I like that! Annie 20:20, 16 October 2019 (EDT)
I would prefer a litte more self-explanatory: a little longer, but what about "only eligible content"? MagicUnk 02:25, 19 October 2019 (EDT)
Well, Our template names tend to be short and/or abbreviated: "Tr", "MultiS", "MultiPubS", etc. Something like "OnlyEligible" would be more in line with the rest of the menagerie. Ahasuerus 12:48, 19 October 2019 (EDT)

Series and international names

Let's start talking about that again. There are two aspects of this:

  • Collect the information
  • Show it in the relevant places (in a book in a language we have the book in).

The second will require development but the first one is a pure data gathering operation for now. A few editors (me including) had taken to adding "Series name in Language: Name" in the notes of the series. Which kinda works but it will be better if we can formalize a bit. I know that two-parameter templates are not workable and creating a template for each language we support will be an overkill so... should we just formalize our practice in the Series Data help page for now? While we figure problem #2 above at least. Annie 12:57, 18 October 2019 (EDT)

Contents section - sorting

As per FR 1315, the behavior of the Contents section of Publication display pages has been changed. In the past, titles without page numbers were displayed in the order of internal database IDs, which are meaningless to users. They are now sorted alphabetically, e.g. see this publication. Ahasuerus 17:34, 20 October 2019 (EDT)

THE CHANGE HAS BEEN TEMPORARILY REVERTED -- see below for details. Ahasuerus 19:34, 20 October 2019 (EDT)
And this means that most of our non-paged collections and anthologies are now messed up - people do not consistently use | because if you are adding all new titles or importing from an existing one, the order was as you add them - and it seems like you do not need the |. It is a good change but we probably now need a report to find all collections and anthologies with no page numbers. Annie 18:00, 20 October 2019 (EDT)
Oh... I didn't think of that. How much of a problem do you expect it to cause? If it's significant, I can change the sorting algorithm back to what it was 2 hours ago until we add "|" values to all container pubs. Ahasuerus 18:12, 20 October 2019 (EDT)
Someone needs to run the queries but based on my own practices and what I had moderated, not negligible. The ID that the contents was ordered based on was not the title ID but the "line ID" - probably from the table keeping the contents. So as long as you added/imported in the order you wanted them in, they never changed no matter what title get merged where. Had it been the title ID, we would have seen the problem on the first merge and the usage of | would have been a lot more prevalent :) Classic case of using an unintended side effect to the full if its potential - while it makes sense for the order to be alphabetical, we need to take care of the works that relied on the old order - and in some cases, we may not have the information anywhere else besides that old order.
And I suspect we have also novels caught into that (order of illustrations or "Afterword" titles that will now bubble above the novel), a lot of the omnibuses and e-magazines as well.
So my preference will be to revert, create the report (any container with more than 1 non-coverart title and no pages numbers) and see what the actual damage is, clear up the ones that will get caught into this, add a warning on the addPub/clonePub/editPub that the order will be ignored and the editors need to use |) and then then implement the change. Annie 18:47, 20 October 2019 (EDT)
OK, the change has been reverted and the FR has been reopened. I'll add your comments to the FR and we'll see where we go from here. Thanks! Ahasuerus 19:34, 20 October 2019 (EDT)
I'm wondering why sorting contents alphabetically would be useful? In my mind, contents should never be sorted. Rather, use of | should be encouraged. Just my 2 centsMagicUnk 00:51, 21 October 2019 (EDT)
We do need a default - there are a lot of cases (older books and new small press anthologies and collections for example) where you can figure out the contents from reviews and publisher advertisements but not the order of the works. In that case, using | will be misleading. So as much as it should not be sorted, we do need to have a default sort - being it IDs or alphabetical. I guess alphabetical is an easy way to make it clear we do not know the order - and make different copies of the same collection look the same. :) Annie 01:27, 21 October 2019 (EDT)
True, using "|" can be misleading in cases. So, to be honest, the more reason I would leave it as-is (ie sorting on ID). This is also the behavior people will expect: "I'm seeing the contents in the order I've entered it". To me, there's no need to start fiddling around with other sorting approaches. I've never found this behavior problematic. Editors know that when they have/want to change the default sorting order, they'll have to use the '|' symbol. If needed/desired, we can clarify in the rules that sorting order is always in the order that the contents was entered - unless - "|" is used. MagicUnk 13:55, 21 October 2019 (EDT)
Someone did - thus the FR and the implementation. Annie 14:16, 21 October 2019 (EDT)
The FR was created based on recent feedback provided by Dave Langford, one of the SFE3 administrators. He noticed that the ordering of the Contents section of this pub was neither alphabetical nor chronological and didn't reflect the actual order of stories in the book. After I explained the current display logic to him, he suggested that it may be better to display unordered stories alphabetically. Ahasuerus 11:33, 22 October 2019 (EDT)
It does make some sense - we do need a default order and alphabetical makes sense more than anything (chances are that we do not have chronological order for most anthologies). We just need to take care of the ones that do rely on the current order - for every collection that is in shambles like this one above, we probably have 5 that look as if they are ordered even if they are not. Doug below made a very good point also - can we have a novel (and non-fiction -- these are the only containers that are also titles that need numbering) always appear with a |1 for example so people can order around it if needed (and not always need an edit if they have afterword and other titles in the work. If the novel needs a page number, they need an edit anyway but if it does not (e-book), why not make it easy)? :) Annie 11:45, 22 October 2019 (EDT)
I personally prefer the way as it is now -- despite it being meaningless for a user. But I can live with either. And don't forget that there is a huge amount of users that just use the DB -- you as the person that enters the book understand the order, someone finding it later does not (or even worse - we have collections which are in different order when they are not). What we do need is to start using | more consistently and clean up the ones that do not (and where we can find a source to confirm) - even if we never re-deploy the alphabetical order. Just on general principle. :) Annie 14:16, 21 October 2019 (EDT)
As a logical exercise in understanding and explaining, how would you choose to pre-populate the page field for publications of the various types? ../Doug H 08:17, 21 October 2019 (EDT)


Various types? Of what? Annie 13:14, 21 October 2019 (EDT)
When ADDING new data, NOVELS have fields for Additional Regular Titles and no spot for the automatically created content title that matches the TITLE's title, and hence no way to enter page number using |. All other data types (ANTHOLOGY, CHAPBOOK, etc) leave it to the user to fill in every contained title along with the page number. IF we were to prefill the page field, would we put in "| n" where n is the line number? or go by 10s to allow someone to put values in between? What number goes in the generated NOVEL title field so people can place interior art and forewords ahead and excerpts and afterwords after? Before we go converting the old stuff, just trying to picture how you'd like it to work in the new approach. ../Doug H 14:50, 21 October 2019 (EDT)
No number goes in front of a novel now - you need to do a post-approval edit to add the page number (being it | or not). Which is part of the point - if you add afterwords during the creation, it always goes after the novel (ID creations and all that). If you need an Introduction, you always need to edit after that to sort out the order. :) Annie 15:34, 21 October 2019 (EDT)
PS: And there is no new approach really here - the | is an old approach. The sorting was briefly changed, I complained that this messes up our current pubs, it got pulled out. :) Now people need to edit a novel post approval only if they want to add a page number or something before the novel; if we change the order, it will mean they will need to always edit for afterwords as well. Annie 16:59, 21 October 2019 (EDT)

(unindent) One thing to keep in mind is that the way we currently display unordered titles is not really enforced by the software. If you repeatedly use Edit Pub/Clone Pub/Title Remove/etc on a pub, it's possible that the ordering may change. There is nothing in the software that makes sure that "the order in which the titles were originally entered in the Contents section" is preserved. Ahasuerus 11:42, 22 October 2019 (EDT)

Thus my "it seems like" above. But the lines for the titles are created in the order they get added in the list, the clone grabs them in the same order as well so even if there is no real enforcement, there is a de-facto one because the IDs get created linearly and you cannot insert something between two other titles (without using page numbers). It is just a side effect, being used to the full of its potential. I suspect that there are corner usecases where this does not hold but for the most part, things stay where you put them. Annie 11:52, 22 October 2019 (EDT)
I wonder if it might be good to have the system automatically add the pipe sorting in the order contents are entered if they are not added by the submitter? ···日本穣 · 投稿 · Talk to Nihonjoe 16:44, 22 October 2019 (EDT)
It wouldn't be hard to implement, but consider the following scenario. An editor is using a secondary bibliography as his source. The source lists the stories alphabetically and that's how the editor enters them. There is no implied ordering, but then the system adds "|1", "|2", etc automatically. The reviewing moderator approves the submission because it looks fine. Post-approval, we end up with a publication record which implies that we know the order of the stories even though we actually don't. That would be rather misleading, I would think.
I suppose we could approach this issue from the opposite direction: have the system display "|1", "|2", etc as the value of the Page field by default. It would then be up to the editor to change or delete the page numbers as appropriate. I am not sure that it would be an improvement, though, because some editors would likely forget to change the default values. Ahasuerus 16:11, 23 October 2019 (EDT)

ISFDB downtime -- 2019-10-21, 10:30am server time

The ISFDB server will be down for maintenance between 10:30am and 11am (server time) today. The downtime will start at 10:30am US Eastern, 7:30am US Pacific, 3:30pm UK time, 4:30pm Western European time. Both the database and the Wiki will be unavailable. Ahasuerus 09:57, 21 October 2019 (EDT)

And we are back, 14 minutes ahead of schedule! Ahasuerus 10:47, 21 October 2019 (EDT)

"Other Sites" split

As per FR 1310, the "Other Sites" drop-down list has been split into two. The first one is called "Amazon Links" and links up to 6 (soon to be expanded to 16) Amazon stores. The second one is called "Other Links" and links to the other third party sites that we support. Ahasuerus 16:01, 23 October 2019 (EDT)

The rest of the FR has been implemented. All ISBNs and ASINs should link to the same 16 Amazon stores now. Unless you change the default behavior under My Web Sites, of course. Ahasuerus 14:41, 24 October 2019 (EDT)

Display changes requested by Amazon

As many of you know, the ISFDB project participates in the Amazon "Associate" program. What this means is that:

  • Amazon gives us programmatic access to its internal database (aka "the Amazon API")
  • when we link to Amazon.com or Amazon UK, we embed an Amazon-issued affiliate ID in the URL
  • when a user follows an Amazon link with our ID embedded and buys a book, we get a few cents per book

The money that we get is typically in the $5-$15/month range and goes to partially offset server costs. In the grand scheme of things it's inconsequential and we could easily live without it. However, having programmatic access to the Amazon database is a big deal since it enables Fixer to create automatic submissions. They make it much easier to keep up with (at least English-language) new books. If we stop embedding ISFDB IDs in Amazon URLs, we will stop making money for Amazon and they will revoke our access to their database.

The latest update to the Amazon "Associate" agreement and the latest Federal Trade Commission (FTC) guidelines require Amazon Associates to disclose that they make money from Amazon links. Here is the specific language that I and, reportedly, many other participants, received from Amazon a few days ago:

  • ... you must include a legally compliant disclosure with your links ... A clear disclosure could be as simple as "(paid link)", "#ad" or "#CommissionsEarned" ... It should be placed near any affiliate link ...
  • ... the following statement clearly and conspicuously appears on your Site: "As an Amazon Associate I earn from qualifying purchases."

I am not thrilled with these requirements because implementing them will make us look more like a referring service and less like a bibliographic site. At the same time I expect that the advantage of having programmatic access to Amazon's data outweighs the disadvantages.

My current thinking is that we could add "As an Amazon Associate ISFDB earns from qualifying purchases -- see the ISFDB FAQ" to the bottom of Publication pages, right under "ISFDB Engine - Version 4.00 (04/24/06)".

For link-level disclosures there are two areas of the Publication page that are affected: the drop-down list under the recently renamed "Amazon Links" and ASIN external IDs. (Note that only Amazon.com and Amazon UK links are affected at this time.) We could display something like "affiliate link" next to Amazon.com and Amazon UK links. The FTC guidelines seem to say that "affiliate link" might not be "adequate" "by itself", but it's open to interpretation. I'd rather wait and see what happens than use "(paid link)" or "#ad", which are misleading. "#CommissionsEarned" may be a fall-back position if "affiliate link" turns out to be insufficient.

So, what do you think? Ahasuerus 16:00, 24 October 2019 (EDT)

Are the covers/images counted as links under this? And if we lose the affiliate, is our permission to use them change as well (I know we do not want to lose it but just making sure we are not missing something in case you do)? Annie 16:20, 24 October 2019 (EDT)
I don't think the covers/images count because those take you directly to the image, which has no obvious way to get to the product from there. ···日本穣 · 投稿 · Talk to Nihonjoe 18:27, 24 October 2019 (EDT)
Probably not for that link disclosure thing but I am not sure if our permission to use the images and link to them directly is tied to the associate program or not. Thus me asking :) Annie 18:47, 24 October 2019 (EDT)
I am afraid I am not really sure what the current Amazon policy re: deep-linking to their images is. Ahasuerus 19:01, 24 October 2019 (EDT)

(unindent) Hearing no objection, so ordered -- FR 1322 "Display changes requested by Amazon" has been created. Ahasuerus 16:48, 21 November 2019 (EST)

New cleanup report -- Mismatched Template Braces

As per FR 1313, a new cleanup report, "Mismatched Template Braces", has been deployed. The data will become available in approximately 5 hours. I estimate that it will find 55 records with problematic notes. Ahasuerus 20:16, 24 October 2019 (EDT)

Most were Dutch and German titles. Probably a lot of copy-paste errors. Amazing it was only 55 :) All gone now. --Willem 03:42, 25 October 2019 (EDT)
Thanks! Ahasuerus 09:39, 25 October 2019 (EDT)
As for why only 55 - these were not that hard to find with Advanced search so some cleanup had been going on ad-hoc ;) Annie 16:45, 25 October 2019 (EDT)

New cleanup report to find references to non-existent templates in Notes/Synopses

As per FR 1314, a new cleanup report, "References to Non-Existent Templates", has been created and deployed. The data will become available around 1:20am server time. I expect it to find 4 records with references to non-existent templates in Notes. Ahasuerus 15:59, 25 October 2019 (EDT)

Advanced Publication Search - Primary Verification Date added

As per FR 1316, "Primary Verification Date" has been added to the list of supported Advanced Publication Search selection criteria. Ahasuerus 19:00, 25 October 2019 (EDT)

Leading and trailing spaces in External IDs

As per FR 1307, the software has been changed to silently strip leading and trailing spaces in External ID values. You may need to do a full page reload (Control-F5 under most browsers) for the new functionality to take effect. Please note that embedded spaces are still disallowed. If you run into any issues, please let me know. Ahasuerus 19:49, 25 October 2019 (EDT)

You are on a roll today :) Thanks for getting this one fixed :) Annie 20:22, 25 October 2019 (EDT)
Sure thing. It helps that I no longer have to spend most of my time on Fixer. It also helps that I have been feeling better lately (knock on wood.) Ahasuerus 11:55, 26 October 2019 (EDT)

Top Voted list changes

As per FR 1289, "Enhance the Top Voted list", the "top voted" section of the "ISFDB Statistics and Top Lists" Web page has been changed as follows:

  • "Top 100 Novels as Voted by ISFDB Users" has been changed to "Top Novels as Voted by ISFDB Users". The maximum number of novels has been changed from 100 to 500, although at this time only 358 novels have more than 5 votes and are eligible for inclusion. The new data will become available overnight.
  • "Top Short Fiction Titles as Voted by ISFDB Users" has been added. The data will become available overnight.

The FR also requests that we:

  • Create sublists for novellas, novelettes and short stories, and
  • Create "most controversial" lists for these title types

I guess we could implement the first request, but we barely have enough short fiction titles with more than 5 votes for a meaningful "top short fiction" list. Sublists would be very short and hardly useful.

"Most controversial" lists are easy to implement, but would they add value? Ahasuerus 17:48, 26 October 2019 (EDT)

What would be on a "most controversial" list? ···日本穣 · 投稿 · Talk to Nihonjoe 16:06, 28 October 2019 (EDT)
Titles which have both low scores and high scores. For example, consider Paraworld Zero, which has three "1" votes and six "10" votes. The SQL code would look like:
  • select std(rating),title_id from votes group by title_id having count(user_id)>3 order by std(rating) desc limit 50
We could change "controversial", which was popularized by Reddit a few years ago, to "polarizing" or something similar. Ahasuerus 16:33, 28 October 2019 (EDT)
That's basically what I thought it might be, but it's good to know for sure. ···日本穣 · 投稿 · Talk to Nihonjoe 16:44, 28 October 2019 (EDT)

Content field and varianting

Can we please disable the contents field when you edit a variant the same way we do for series and series number and make it derived from the parent? We will never variant omnibuses with different contents so it can be safely deriving from the parent (the way series do) or moving to the parent when varianting up. And it will also mean an editor does not need to remember to repeat the same value in each variant after they variant omnibuses. Annie 17:19, 29 October 2019 (EDT)

After sleeping on it, I think treating the "Content" field the way we treat the series field and the series number field makes sense. We will need to update the "Make Variant" software to move the "Content" data to the parent title and we will need a new cleanup report, but it's all doable. Ahasuerus 15:08, 31 October 2019 (EDT)

Imadjinn Awards nonfiction category

Can we add a "Best Non-Fiction Book" category to the Imadjinn Awards? Some of the winners are within the scope of ISFDB. Thanks! ···日本穣 · 投稿 · Talk to Nihonjoe 19:10, 30 October 2019 (EDT)

I thought moderators were able to create new award categories. Do you see "Add New Award Category to This Award Type" within the "Editing Tools" section of the linked page? Ahasuerus 14:32, 31 October 2019 (EDT)
I guess I missed that since it's so far down the page. All created. (^_^) ···日本穣 · 投稿 · Talk to Nihonjoe 16:17, 31 October 2019 (EDT)
Okay, Imadjinns are entered through 2019 winners. ···日本穣 · 投稿 · Talk to Nihonjoe 17:17, 31 October 2019 (EDT)
Excellent! Ahasuerus 17:18, 31 October 2019 (EDT)

Advanced Publication Search - Secondary Verification Source added as a selection criterion

As per FR 1304, Advanced Publication Search has been enhanced to support secondary verification sources.

Note that you can use this functionality to look for suspect verifications. For example, it turns out that we have 4 publication records which match the following selection criteria:

  • Publication Year starts with 20
  • Secondary Verification Source is exactly Bleiler Early Years

Since Bleiler Early Years was published in 1991, the 4 verifications found by this report are presumably in error. We may want to follow up with each verifier to determine whether s/he clicked the wrong verification source or whether s/he meant to use the "N/A" button. In at least one case the verifier apparently misunderstood how secondary verifications work.

As is typically the case when adding new dynamically changed drop-down lists, you may need to do a full page reload (Control-F5 under most browsers) to make everything work correctly. Please let me know if you run into any problems.

Next I plan to create a new cleanup report to find publications whose secondary verifications are "out of bounds". Ahasuerus 14:30, 31 October 2019 (EDT)

Awards titles when a title is changed

When we create a new award, its title (which shows only when you press Edit - on the view screen you see the title of the actual linked work) comes from the Title connected to it. Once created that value is not changeable. So when you change the title of a record (for capitalization purposes or and/& or dropping subtitles and so on or something along these lines), the Award title remain as is. So there are two choice:

  • Leave is as is - which I do not like on general principle - it is just sloppy :)
  • Delete the award and re-add it again (which while doable is probably not what we want to be done).

Can we either sync these titles to the one of the titles or make them editable (foe example here)? Annie 15:11, 31 October 2019 (EDT)

It's not just the "Title" field that can get out of sync with the title record, it's also the "Author(s)" field. There is nothing stopping an editor from re-pointing an award record to a completely different title record with different authors.
As for the reasons why the software works the way it does, well, it's kind of complicated.
The original award system was rather rudimentary and incomplete. When I rewrote it ca. 2013-2014, I replaced some components and kept certain other components. One thing that I did was separate "awards associated with titles" from "awards not associated with titles". The latter have titles and authors of their own; the former use the title/author data of the linked title record. In an ideal world, "awards associated with titles" wouldn't store separate title/author data elements in the database -- as you said, they are pretty much useless. However, the two types of awards share underlying database tables. Moreover, there are quite a few places in the code that expect these award fields to be populated. I ended up with a compromise solution: when a "title-based award" record is first created, the software copies the title record's title and authors to the award record, but then they are never used except in ineditable fields when editing the award record.
I guess the easiest way to get everything in sync would be to use the title/author values associated with the currently linked title record to populate the ineditable "title" and "author(s)" fields on the Award Edit page. Ahasuerus 15:37, 31 October 2019 (EDT)
Yeah, I was just dealing with a title this morning and forgot about the author but I can see how we have the same problem there. :) We also can make them editable (moderator only if need be) but that will mean remembering them AND a new report so we can clean the discrepancies. We have a similar case with the reviews - and there the title and author are editable (most likely because they are shown inside of the container that contains the review). But if we can just use the linked title, it will mean we do not need to worry about updating so that is better :) Annie 15:49, 31 October 2019 (EDT)

Elantris

Hebrew title

I added this title, but since I don't speak or read Hebrew, it would be good for someone who does to review it to make sure I didn't inadvertently make a mistake. Thanks in advance! ···日本穣 · 投稿 · Talk to Nihonjoe 20:17, 31 October 2019 (EDT)

Russian, Polish, Thai, and Portuguese releases

There are apparently Russian, Polish, Thai, and Brazilian Portuguese releases of Elantris, but since I don't speak or read Russian, Polish, Thai, or Portuguese, I have had difficulty finding them. I tried poking around, but couldn't find much. Any help with that is appreciated, too. ···日本穣 · 投稿 · Talk to Nihonjoe 20:22, 31 October 2019 (EDT)

I will add the Russian and Polish ones Annie 20:23, 31 October 2019 (EDT)
The Russian and the two Polish editions had been added. I also threw in the Bulgarian, Czech, Hungarian and Turkish editions for no extra charge. I saw two Romanian ones as well but we have a Romanian editor so I will ping him to see if he would like to add them and an Indonesian one (which I do not know at all but we can try to add) :) Annie 21:32, 31 October 2019 (EDT)
Awesome! Thanks! ···日本穣 · 投稿 · Talk to Nihonjoe 15:44, 1 November 2019 (EDT)
Any time. And I asked the Romanian editor to add the Romanian ones (and approved them and massaged them into shape). You may want to ping PeteYoung for the Thai one directly - he may not be paying attention to the Community group :) And probably Dominique for the Portuguese one(s). Annie 15:51, 1 November 2019 (EDT)
I've asked Pete, but I can't find an active user name Dominique. Do you have a link? ···日本穣 · 投稿 · Talk to Nihonjoe 15:59, 1 November 2019 (EDT)
Ah, sorry. I meant our very own Linguist - and I think he can also check the Hebrew one :) This is very useful for finding who can help with exotic languages when you do not know off the top of your head. Annie 16:04, 1 November 2019 (EDT)
Yup, I created that page. :) ···日本穣 · 投稿 · Talk to Nihonjoe 17:05, 1 November 2019 (EDT)
I'll have a look at the Hebrew and Portuguese ASAP (meaning later to-day). Linguist 05:37, 2 November 2019 (EDT).
Dealt with the Hebrew one here. As for the Portuguese pub, either I'm utterly plotzed this morning, or it's not there ! :o) Linguist 07:21, 2 November 2019 (EDT).
We don't have one on ISFDB, but I've seen a few mentions of it online. I'll see if I can find one of them. ···日本穣 · 投稿 · Talk to Nihonjoe 21:22, 15 November 2019 (EST)
Check GoodReads. I think I saw some there when i was chasing the ones I added. Annie 21:53, 15 November 2019 (EST)

Show pub information show when hovering over images on title covers page?

User:ErsatzCulture has created FR 1317, "Have pub information show when hovering over images on title covers page". Here is what the non-technical part of the FR currently says:

One of the things I like doing in ISFDB is browsing the cover art for a title, and seeing how styles and tastes change over time or between publishers.
However, IMHO it's a slightly "opaque" user experience, in so far as the page (e.g. http://www.isfdb.org/cgi-bin/titlecovers.cgi?28692 ) just presents a bunch of cover images at you, with no context about which pubs they came from, or indication of why they are in the order they are, unless you click through to an individual publication page.
It would be possible to add information labels for each image, but then the size of the page (in terms of screen real estate, not number of bytes) could get blown up quite a bit.
Could I propose a solution - albeit one only usable by desktop users - where if a user hovers over a particular cover image, information about that publication is overlaid on that cover image. (I think this is a UI concept "inspired" by some other sites/apps, although I can't think which ones off the top of my head.)

I agree that it would be useful to provide additional context on the "All Covers" page. However, I am not sure whether it would be better to show the additional information as "mouse-over" or to display the basics like "Lion Book 1953" under each image. We could even combine the two approaches by displaying the bare-bones data under each image and providing more information via "mouse-over". Ahasuerus 16:46, 1 November 2019 (EDT)

I vote for not relying on hover/mouse overs only... or at least to make it optional or even two separate pages? I want to even be able to search (Ctrl+F and so on) on the page for "Lion Books" for example and see all the covers for that publisher from that pub - without needing to hover over all of them Annie 17:10, 1 November 2019 (EDT)
I would split the discussion in two: 'mouseover for extra info which doesn't use additional real estate' and 'what info can we add to cover pages to allow searches'. The former is easy to agree to, the latter warrants additional scrutiny imo since it'll use up screenspace, no? MagicUnk 00:04, 2 November 2019 (EDT)#
Yes, my reason for proposing overlays was because of not wanting to bloat out the page, and having them only appear when hovering means that if you don't want to see that info, you don't have to.
Here is a screengrab of my dev version. This has been hacked to show the info on all covers, just to give a better idea of the info and colour coding I'm suggesting - in reality only one image (at most) would ever show this at a time. The publisher ID is shown as a placeholder for the publisher name, because the latter isn't currently pulled from the database when producing this page, and there was no point in altering that query if this idea isn't going to be approved. ErsatzCulture 11:33, 2 November 2019 (EDT)

default clones to having a date of 0000-00-00?

My most common error when editing is to forget to clear the date when I'm adding a clone. It would seem that when you're adding a new printing, it would always have a different data. TAWeiss 18:33, 1 November 2019 (EDT)

Clones are also useful when you are adding ebooks and/or paperbooks - where the date does often need to be the same. But I won't be opposed to making the field empty instead. Annie 18:47, 1 November 2019 (EDT)
I think an empty field would be our best bet. Ahasuerus 19:06, 1 November 2019 (EDT)
Since clones already have reuse check boxes, how about a "Reuse publication date?" that is unchecked by default? -- JLaTondre (talk) 19:12, 1 November 2019 (EDT)
Sure, we can do that. Ahasuerus 19:20, 1 November 2019 (EDT)
I like that MagicUnk 23:44, 1 November 2019 (EDT)

Flag to mark publisher name is author name?

I'm increasingly being annoyed with all the self-publishing through Createspace that causes publisher records to proliferate and starts to clutter searches with 'useless' hits. Could we have a flag added to the publisher records meaning something like "this publisher name is the author's for self puplishing" (don't have the inspiration to come up with something better, but you get my drift eh? ;) MagicUnk 23:56, 1 November 2019 (EDT)

Not that I do not want the flag but consider the publisher ‘Latin Goddess Press’ for example. Will you check the box there? Does making a company make it really that different? Or Eve Langlais (Look up the name as a publisher name). And then there are presses that start that way and branch out. Who is going to monitor when that happens and remove the checkbox? Now, a checkbox that says that the author name is used as a publisher name - that makes sense. But then again, see the Goddess publisher. :)Annie 00:07, 2 November 2019 (EDT)
I may not exactly have been clear, but that's what I'd want, a flag that says author name used as publisher name. And yes, there are some ambiguous cases where it's not so clear cut, or may change over time, as you point out but I believe the vast majority of these pub records would be correctly tagged. (As an aside, I was thinking about adding an 'imprint' flag too, but that would require much more maintenance, with all the takeovers and subsidiary vs. Imprint and whatnot so I don't think an imprint flag would be workeable) MagicUnk 03:52, 2 November 2019 (EDT)
Let me make sure that I understand the proposal correctly. We would add a new check-mark box or a "Yes/No" drop-down field to the Edit Publisher page, right? Where would this flag be displayed/used? In regular and Advanced publisher searches, I assume? Any place else? Ahasuerus 11:52, 2 November 2019 (EDT)
That's right; checkbox edited & displayed on the publisher page, and used in searches. MagicUnk 16:33, 2 November 2019 (EDT)
Don't show in the Publisher directory or mark them somehow there so it is clear what they are? Quite honestly, if we are reopening the Publisher page, we may as well also add a Language there - the same way we have for authors - while there are a few multinational publishers, most of them are single-language and I would love to be able to find all Hungarian publishers for example. Annie 15:10, 2 November 2019 (EDT)
Agree on the language. Would be useful for me too. I don't suppose we can add country, do we? (I suspect we'd run in the same trouble as I said above about adding an imprint flag) MagicUnk 16:33, 2 November 2019 (EDT)

Binti: The Night Masquerade

Binti: The Night Masquerade is one of those novella/novels cases that are too close to call even on a complete word count (to the point where it was eligible for both for most awards). It ended up nominated for 3 awards, all 3 as a novella. We have it as a novel. Before I leave a note there explaining why (we have some earlier novel winners as collections so we have precedents), I wonder if we should keep it as a novel or convert it to a novella. Thoughts? Annie 13:56, 8 November 2019 (EST)

I can do a word count estimate on it. I'll have to find a link to that Google Sheets tool, though. I have it somewhere. ···日本穣 · 投稿 · Talk to Nihonjoe 14:46, 11 November 2019 (EST)
I own a copy, did a word count when I primary verified it back then and had entered the results into the title record, including some more infos about it. Somebody must have deleted it! I'll look into an older backup and see if I can find the note's contents again. Jens Hitspacebar 16:30, 11 November 2019 (EST)
Found it in the database backup from 2018-03-31, the day I had primary verified it, and added the note's contents back to Binti: The Night Masquerade. Whoever deleted the note must have done it between 2018-03-31 and 2018-04-07, not more than week after I had added it. That's really annoying if it was done on purpose. Can someone please can take a look at the note now and check if the wording is clear enough so that it's not deleted again because someone thinks that it's worthless information? Jens Hitspacebar 17:27, 11 November 2019 (EST)
Good enough for me. Thanks for adding it. No clue why someone would delete it (but it is annoying indeed). Annie 17:33, 11 November 2019 (EST)

Proposed change: make the position of the search box in the nav sidebar "sticky"

Since becoming a more frequent user of the site, something that is increasingly annoying me - probably far more than it should ;-) - is the way that when a page (re)loads, you always go to the top of the page. (To be more exact, to a point where the first/most relevant input field is visible and in focus, but this is AFAIK much the same thing in practice)

This is annoying in scenarios like the following:

  1. Go to a long page with lots of links e.g. http://www.isfdb.org/cgi-bin/se.cgi?arg=venus&type=Fiction+Titles
  2. Scroll down to somewhere near the bottom of the page/table, and click on a link (title, author, doesn't matter)
  3. Decide that the page you're looking at isn't relevant, and press the browser's back button to go back to the results to see if you can find a better one
  4. Find that you are back at the start of the results, and now have to manually scroll back down the page to find out where you were before

Over the weekend I had a look through the site's code, and found that this behaviour is deliberate. Whilst focussing on the input field makes sense in the context of a user searching on a lot of different values, or making edits, personally I think the knock-on effect it has on more casual navigation is not ideal.

I would like to propose a solution for which I have a barebones working demo, to be found here. Note that when you scroll down, the search box always stays visible on the page, and as a consequence, if you click on a result and then use the browser back button to return to the list of results, you'll be at the place in the list you were previously at, but at the same time the search field will be focussed, retaining that aspect of the current behaviour.

(Note: because this is a rough demo, all the title and author links in the results table go to the same fake title page, and all the other links on these pages are broken.)

There are other potential related changes that could be made - some of which are discussed in updates to this old ticket, but those might well require more research and development, whereas the change as implemented in this demo is largely complete as-is, and should be fairly straightforward to add to the site.

Thoughts? —The preceding unsigned comment was added by ErsatzCulture (talk • contribs) . 11:01, 11 November 2019 (EST)

I like the moving search box. I also agree with the sentiment regarding having to scroll back down a large page. It does make some things more difficult. ···日本穣 · 投稿 · Talk to Nihonjoe 14:44, 11 November 2019 (EST)
As I said on SourceForge (see the discussion linked above) earlier, I like the proposed functionality. However, it requires a fairly recent browser version to work correctly. Based on our experience over the years, many of our users are suck with old browser versions for various reasons, so we need to make sure that the change doesn't adversely affect the behavior of old browsers. ErsatzCulture and I are currently discussing technical options on SourceForge. Ahasuerus 12:50, 12 November 2019 (EST)

The Russian awards

I had been working on some Russian titles and keep bumping into the awards so can we add:

as a start. All of those should be eligible for addition here... :) Links to their Fantlab pages - actual pages linked there but if you read Russian, that is the fastest way to get the idea of what is what... We can also go one by one as well but... might as well add the big ones together. Thanks! Annie 19:52, 11 November 2019 (EST)

Sure, I'll be happy to add them if we have the manpower to enter the data. IIRC, the last time the issue of Russian awards came up, we also mentioned:
Ahasuerus 09:24, 12 November 2019 (EST)
There are a few more of we want a good coverage. The Efremov for example. :) But we need to start somewhere. Started with a list of 20 and narrowed down a bit as a start. I would rather start with the awards that are active and visible and work from there than work on an award that had not been given since 1996 as a start. So we either dump all of them in and deal with empty awards for awhile or we take it slow. I can add a few more I want if we go for all at once. :) Annie 11:03, 12 November 2019 (EST)
"Take is slow" is perfectly fine by me. If there are no objections over the next day or two, I will create the requested award types. Ahasuerus 12:45, 12 November 2019 (EST)

(unindent) The requested award types have been created. They may need further massaging; I believe moderators can create and approve "Edit Award Type" submissions. Ahasuerus 16:36, 14 November 2019 (EST)

Yep. Thanks. I will work on them this weekend while Fixer is in his early monthly stages :) Thanks for adding them. Annie 16:48, 14 November 2019 (EST)

Who's the image source?

Someone recently uploaded a new cover scan over one I had loaded some time ago. It's a better image, so no problem there. My question is why does the text under the Fair Use Image Data state that I am the source and not the more recent uploader? ../Doug H 08:19, 12 November 2019 (EST)

That is weird. I even tried to delete your old image and that still left the license in place. And looking at the history, Mavmaramis did try to set the license to his name (Source=Scanned by User:Mavmaramis is there in his edit. So... a bug maybe? Or something else is going on. In all cases, we probably will need to see how many others are like that... Annie 12:41, 12 November 2019 (EST)
This is a known problem. See the helptext here. The image data must be changed manually (unfortunately). --Willem 13:01, 12 November 2019 (EST)
Aha. I do not do a lot of images (and I never replaced one as far as I remember) so I missed that. Thanks for clarifying! Annie 13:13, 12 November 2019 (EST)
And by description, it means all variable content: description, publisher, artist and source. Might be worth noting on the upload page. Thanks for the response(s). ../Doug H 14:31, 12 November 2019 (EST)

The Marvel series reorganization

We had the Marvel series organized based on where they belong on the timelines and the movies/series/comics split. Which made it useful for finding what books fall in line with which release.

For some reason, they had been reorganized in the last week or so based on their main character (and from looking at most of the series, not even based on the character itself but based on the brand name only - and most of those do have more than one incarnation). As we do not have the ability to have multiple series, we always have to chose but can whoever is changing that explain their reasoning and why such a huge rearranging of series had not been brought up to the Community before destroying the old organization and all the work that multiple editors had put into it? We may decide that we want them the way they are now but such a large scale changes without a single notice anywhere is against the spirit of the project. Thanks! Annie 12:26, 12 November 2019 (EST)

Since I am guilty again and the reasons were in part the same, I have answered it here, Christian Stonecreek 14:24, 12 November 2019 (EST)
So are we leaving it this way? TAWeiss 21:47, 12 November 2019 (EST)
Surely not, but it seems to have been discussed first. Stonecreek 00:24, 13 November 2019 (EST)
Lumping all books with the same characters in the same series as opposed to following the universe development (as was the old series structure) just sounds a bit incomplete these days. It was not a bad approach 5 years ago but things changes. But I agree that we need a discussion and if most editors prefer character based series, so be it. Annie 02:05, 13 November 2019 (EST)
What late universe development? Marvel had from very early on the tradition of guest-starring and has continually built on it with overlapping story arcs. Still, the individual title series ran on, with some special issues or series thrown in.
With this background and the question posted above, I propose to go on with the re-structuring. The past development (see the examples in the discussion pointed to above) has shown that we as a community had lost the sense of organization for such a complex and inherently illogical structure. Christian Stonecreek 09:59, 14 November 2019 (EST)
There are two ways to look at that. Is it more important that a book is about Spiderman or is it more important where in the timeline it falls and which novels connect to it based on the timeline? In a perfect world, we will be able to do both. As it is now, one of those will need to be offloaded to a tag. So even if we do go on and build again back based on the characters, preserving the rest of the information in tags should be mandatory. Or in notes where that makes more sense. If everyone prefers the character based, then so be it. But let's ping the few editors that were doing a lot of work on that series lately and check on opinions. :) Annie 10:14, 14 November 2019 (EST)
For Marvel, I'd think it'd be a futile attempt to implement a timeline, since fiction titles may be placed in every possible time-slot or - even more often - any point in time will not be identifiable. Christian Stonecreek 10:24, 14 November 2019 (EST)
Marvel (as a company) is reorganizing into waves (because of the movies but the comics and the novels are getting also reshuffled) - similar to how Star Trek and Star Wars (pre-republic and so on) had been doing. So when the dust settles, most novels can fall into proper timelines groups. We can wait for the dust to settle but please, let's not lose the information by just moving them and not adding either notes or tags. Annie 10:28, 14 November 2019 (EST)
At the very least, I would recommend grouping the books related to the Marvel and X-Men movie series. Simply lumping by character loses the connection in the stories, and those characters are different in many ways from their traditional representations. Presumably, this would apply at some level to the DC metaverse. TAWeiss 10:52, 16 November 2019 (EST)
I agree. Character based series for the metaverses turns us into a glorified Listmania - and when there is a SpiderMan/Avenger novel, it will get even funnier and absolutely useless. Of course, it would have been much easier to figure out the reorganization if the work already done was not wiped out already... :) Annie 21:18, 16 November 2019 (EST)
Well, more or less obviously, I don't agree. This approach has lead (and will lead again) to the mess that was and is still not repaired. Titles with more than series-defining character would have to be grouped into the overall Marvel metaverse. This would follow the way Marvel organizes its uni-/meta-verse: by having the character-driven title series and the occasional crossover story-arc (like 'Civil War'); thus it would be the most easy-to-grasp way of ordering things. A possible way to find story-arcs would be tagging. Stonecreek 09:49, 18 November 2019 (EST)
So, under your scheme, a crossover between Spiderman and the Avengers will go under which series? You need to chose one and then you will have both the second character and the era in the tags (and for completeness you will need to add the main character as a tag as well so people can only look in one place for all books related to a character and do not need both a tag list and a series...
The fact that you could not figure out how to clean-up and complete the work does not mean that the only option was deleting all of it. Annie 11:29, 18 November 2019 (EST)
A crossover between Spiderman and the Avengers would obviously go under Marvel metaverse. As Doug has pointed out: all attempts to get a consistent organization of the series by sticking to the publisher's 'scheme' will be proved futile, since it is per se not consistent. Christian Stonecreek 23:23, 18 November 2019 (EST)

(unindent)After some thinking, here is an idea:

  • Move all the novels which are in the movies/series metaverse into their own subseries under the metaverse (Marvel Cinematic Universe).
  • Use the Infinity saga 3 phases to split the novels into subseries (with further subseries if needed based on specific storylines or complete character-based sequences). That means that if a book falls after "Age of Ultron" but before "Endgame", it gets grouped with the rest of the books that are connected to it and all the post-Endgame novels are grouped together.
    • The titles of a lot of the novels and stories will need to be restored back to what they were before half of their titles (as recorded on Title pages) were stripped to be used as series names. All PVs will be notified for any change.
    • We should probably also have a "uncategorized" bucket for novels which we cannot find enough information about... but we can work on that.
    • There are probably a few novels that cross between eras - depending on the numbers, they may need another high level series.
  • Character names can be added as tags.
  • All non-MCU but still Marvel novels (the ones that are in the comics universe but not in MCU - if we do have any) stay in their original place (aka per character) until we have enough of them so that it makes sense to change.

That way we will create more than a Listmania list of "these books have this character but some of them are over there and not here because of a crossover" and will make it easy to find a novel or see what novels are available for a certain era in MCU (and then you can get a character-based list based on the tags). Any feedback is welcome. Without the ability to add more than one series per book, we need compromise and as we cannot use the Pub series for these (translations and what's not will stick them in different places), we need a rational plan that makes sense and does not turn us into one more incomplete list of books on the internet. If noone disagrees, I will work with the records and lay down the proposed separation here before I go and change everything (probably next week). Once we sort that one out, we can work on the DCU and DC series. One at a time. Annie 11:29, 18 November 2019 (EST)

I'm not much of a Marvel fan, so have been following this thread without understanding a lot of the details. I tried to figure out what was going on by looking for Marvel's take on how to organize the material, thinking that should for the basis for our series. Seems that even they don't have one way to deal with it. The medium (film, comic, TV, etc) seems to loom large as there are differences for the same character between them. Their fandom seems to recognize various universes (e.g. 616), but even these cross-over. Much as I personally dislike tags, I think the Marvel (Meta)(Multi)Universe(s) is too big to be considered a hierarchy of 'series' and should be abandoned and that sets of tags - like universe, character, medium be established and used to link stories together. Maybe series could be used to link small things with clear connections (like movie novelizations). ../Doug H 12:00, 18 November 2019 (EST)
The MCU (the movies/series universe) is basically its own thing - separate storylines and timelines (although they did versions of most of the main storylines from the main universes). But that is exactly the point - a novel about Spider Man in the MCU has the same name and maybe the same storyline as one in 616 (also known as the main comics universe) has as much to do with a Spider Man novel in 616 as with a Batman novel: someone fights crime and monsters - all the details are wrong and the novel can be either for Parker or for Miles Morales (or some other incarnation). Sticking these under one "series" just because they are both Spider Man novels does not make much sense.
We can always just organize based on the main line, with occasional series inside and be done (kinda what we do for Stargate SG-1/Stargate Atlantis. The crossovers across universes in Marvel's lines are not as many as these in the SG franchise (at last the SGs are in the same timeline and know about each other) and most of them are during the big events so they will fall into these really.
And Marvel are still shifting things. The whole three phases thing did not show up in any of their communication until a couple of years ago (if that). So I expect the dust to settle at some point... Annie 12:27, 18 November 2019 (EST)
Rather than trying to create an organization, can we find an authorative source and use theirs? And if there are multiple, let's argue about which to use, rather than what to create. We are primarily bibliographers rather than generators of information about these stories. ../Doug H 12:39, 18 November 2019 (EST)
Marvel Fandom: here is based on main groups and lines. Note the "Other Novels" bucket and the "Marvel Novel Series" which tend to shift often and get re-categorized. Wiki's list is just a flat list. So is comicweb. Marvel itself had never had a complete list anywhere. The Titan novels (here are kinds a series in their own as are the Doctor Who ones - they hold the license. So... make your pick. It's one of those "it's complicated" :) And sometimes we do need to order things that noone had bothered to yet. Annie 12:57, 18 November 2019 (EST)
It would seem that just re-organizing the MCU stories into their own hierarchy is relatively straightforward change that does not impact the majority of the entries, but does impose a logical structure on those titles. (As a fan of the series, it's what I'd expect to see.) Should we do the same for the other movie novelizations (Fox X-men, Daredevil, Blade, Elektra, Fantasic Four)? It would seem better to leave them be since they are more localized (though the X-Men ones should be pull their novelizations into their own subseries). TAWeiss 17:59, 18 November 2019 (EST)
Do we want to try to compile a list of the MCU ones so we can see what is in there and then decide how we organize them? I would say one at a time. Let's deal with the MCU first, then see how it looks and decide if we need to pull/change more. Most of the DD/Elektra (pre-MCU, not anything based on the current series), FF, Blade and the older X-men are pretty self-contained anyway... What do you think? Plus that can give us a blueprint for sorting the DC mess as well where it is at least as fun (even if DC-TV is mostly series and not movies based, they did build a separate universe). But one at a time. Annie 18:24, 18 November 2019 (EST)
Starting working on the list here —The preceding unsigned comment was added by Taweiss (talk • contribs) .
Thanks for working on this! Annie 15:20, 24 November 2019 (EST)
Finished listing out the MCU novels. There are some bridging material as well that fits between movies and some prequel material. It may not sort well into phases, but is consistent with the overall story and characters. TAWeiss 18:46, 24 November 2019 (EST)

A proposal to solve the art battles

After I have been asked to redefine the language of a piece of cover art for which the title is stated in English on the copyright page to German, there has been some conflict. In my opinion a 'reality' in which paintings are assumed to be made up out of language and not by using brushes, pencils & colors, shouldn't be the basis for a database that is enlisted to give a picture of reality - and it doesn't get better by further assuming that the reproduction on the cover (or inside) of a foreign publication is redone or translated by using a different language denominator for the variant, which does mark for the unsuspecting eye that somehow words of the different language were used in the reproduction. This all just is done to have a picture or list of the languages a piece of art is published in (with no language involved in the artwork at all).


Now, to repeat: I strongly think that this is a reality-bending approach that stands against plain logic (and our goal to display aspects of reality). However, what about a totally different approach that even more people might be interested in (for example me). The idea would be to display the country of issuing of a given publication, at least on the title level list of publications, for example by using standard abbreviations (US, UK, FR, RU, DE and so on). For most publications this should be quite easily to obtain via the ISBN (for others there obviously would be work involved, but it should be possible to adapt to it, most likely via the country a publisher is situated).

This way we would get rid of the conflict and the unreality bias, but would even gain more information, for example on which side of a given ocean a publication with purely English, French, Portuguese or Spanish titles in it was published. Stonecreek 06:03, 15 November 2019 (EST)

Having thought again about it, it might be necessary to go the way via publisher, perhaps by entering a field for country?. Stonecreek 10:58, 15 November 2019 (EST)
You know, that is not a bad idea IN ADDITION to a language. :) This way we will have both the language (so we know that the cover had been used in German for example) but also where in the German-speaking world. However, a few pesky details. What country will be assigned for the following cases?
  • Russian language book published in Germany
  • US publisher printing in Canada
  • Thailand publisher publishing in English and printing in China
  • Dutch language book from a US publisher printed in USA
  • Dutch language book from a US publisher printed in China
And what is your proposal for cleanup of the existing 184,457 covers and 231,588 interior art records and assigning their countries? We cannot just go one by one and we cannot assume that language means country.
Also please note that regardless if this proposal is approved or not, the current rules still apply and you cannot NOT conform with them. And even if it is approved, it will significant development effort and we cannot just suspend the rules in the meantime or ignore editors that refuse to abide by them. Annie 11:53, 15 November 2019 (EST)
It sounds like there are two separate questions here. The first one is how we should record a COVERART title which uses the same artist name, the same title and the same art/painting, but is associated with different translations of the same book. For example, George Orwell's Nineteen Eighty-Four has appeared as 1984 in dozens of languages. If a French edition were to use the same cover art as a Dutch edition, should the two COVERART titles be merged or varianted? The current policy is that they should be varianted.
The second question is whether we can record and display the country of origin for some of our records, be they titles, publications or publishers. Publications would be relatively easy to do, but we'd need to decide how to handle simultaneous publications. There are quite a few publishers with offices with multiple countries these days. Also, a lot of independently published books appear on Amazon.com, Amazon UK, Amazon CA, Amazon AU, etc almost simultaneously.
Publishers would be even harder to associate with countries, because a publisher, especially a small one, can easily move to another country. Not to mention that countries' borders can change over time, countries can break up, etc. And I can't think of a realistic way to link title records to countries.
I should also point out that, although "countries" and "languages" overlap, there is no one-to-one correspondence. As Annie suggested, certain languages like Arabic, English and German are used in multiple countries while many countries have publishers producing books and magazines in multiple languages. Ahasuerus 16:44, 15 November 2019 (EST)
All the problems you name are non-existant with the approach of dropping the language for art titles. On the contrary, it would help to solve them. Let's take the example of a Russian book published in the USA, and let's take the example further by assuming that it's a book about early speculative fiction with a reproduction of the cover of this publication on its cover (titled 'De la Terre à la Lune / Autour de la Lune' on the copyright page), and reproductions of the cover art pieces of this, this and that respective publications, with additional examples from other countries thrown in. One can only presume, but according to your scheme, I think all the art pieces would get the English language attributed (since it's a US publication), or maybe the Russian? With no language attribute for art titles (since no language was used in creating them), the problem of assigning a language to them wouldn't even arise! Stonecreek 02:17, 16 November 2019 (EST)
So let's delete and lose information just so that you do not need to abide by the rules of the site (the ones you disagree with anyway)? :) That's what variants are for - put the original as the original, then variant the reproductions. We are a DB - advocating the removal of information and various changes in the rules (hide languages inside of pub lists for example or hide dates the same way) which make the information either hard to find or impossible to decipher kinda sounds against the best interests of the project. Annie 21:15, 16 November 2019 (EST)
Yes, we would lose erroneous information (language that does not exist), but I'd think it is a goal of ISFDB to enter correct information, not fake news. Stonecreek 01:31, 17 November 2019 (EST)
The language assignment shows what language was the book that used the cover in. How is that fake news? Or are you claiming that the books do not have language either? Don't think so. You keep getting stuck on putting an equal sign between coverart and cover art. The first is our record that has the art but also has notes, and variants, and language and exact spelling of the artist and so on. The second is the piece of art - which does not have a language. Or multiple spellings of the artist.Annie 02:05, 17 November 2019 (EST)
PS: Just because you do not find that information useful, does not mean that noone does. I find it fascinating to see how many different languages and cultures use certain covers for example (probably the only thing about covers I care about). However, if the consensus had shifted and we had agreed to merge, I would have not gone against it. There are other things in the DB I never look at or care about but as someone may find them useful and we are recording them, I record them on my books, moderate them and even mentor new editors to add them. It is all in the balance. Hiding and removing information, even just obscuring information, just because we do like it or would never use it or do not believe it should be recorded will lead to a degrading quality quickly. You know, I do not care about under what exact author name had a story been published or what spelling the editor of a magazine used for the title - after all they have legal names and the stories have titles. Should I start deleting pseudonyms and variants? Surely having the same author spelled in 10 ways is useless information? Or having the same story spelled in 4 ways because of a comma or a hyphen? I find that as weird as you seem to find the idea that the cover should share the language of the book it belongs to. So shall I just go against the rules and the consensus and make them look how I want to? I know that I will never get the consensus to shift so I just implement the rules as they are - small price to pay for having ISFDB and being able to help. When we go on the slippery slope of "an editor does not like this so they do whatever they want", that becomes a valid question. Let's not go there, shall we? :) Annie 22:37, 16 November 2019 (EST)
Again: they can't use a language that doesn't exist. The cultures that use a particular work of art are covered by the country of the publisher more properly! A Russian book published in Germany would be aimed at (a part of) German culture, just as this is aimed at a part of German culture interested either in learning English or in science fiction (or both).
Let's take another example, Tom Disch's Endzone. (Un)fortunately it has no cover art credit, but please tell me, if it had, what should it's language be? 'Endzone' is a valid title both in English and in German. The book is categorized in English, although more than half of the text is in German (the translations and most of the essays). As is easy to see the publisher is situated in Germany, and a cover artist would presumably be one with a working language of German (the publisher's designer is). And for the interior art: Does its 'language' depend on where in the book (in an English or in a German part) it is printed (but what if it's printed in between)?. Or shall the title rule in this case?
It's fine for you to be interested in art (I am also, but perhaps to a slightly smaller degree), but we are not an art database, instead one that deals with speculative fiction. All those pointlesse debates that arise by assigning language to artworks pointed to in the paragraphs above would not come up, if we drop this made-up assumption. Christian Stonecreek 01:31, 17 November 2019 (EST)
Language and country is not the same thing. And the languages we have, the countries we don't. Come up with a plan on how to find the countries of all books in the DB? And you never answered which country will be chosen in each example above. I like the idea - we were talking abour adding both languages and countries to publishers somewhere a few weeks ago. But as an addition, not as a replacement. And for a book (and a cover) published in Kiev (for example) in 1972, knowing if it is in Ukrainian or on Russian is a lot more important than the fact that it is in Ukraine, USSR. Or that a Russian language book in 1980 was published in London from a UK publisher. From cultural and historical and bibliographical perspective anyway.
For multi-language books, how do you chose the language for the reference title? Someone decided that the Collection is an English title somehow. Same logic applies. If anything, it is the non-art title that is jarring here :) We do need "multiple" for these books (a lot of art books are like that as well). And fascinated and interested are different things. I can live without all the art here. But as we have it, let's not hide it and let's make it as easy to find the information for it as we can. I get it - you do not like it. But you cannot get anyone to agree with you either and support you in a rules change. Get the support, change the rules, I will be the first to help with the cleanup (I seem to always be doing some cleanup). Are we really spending our time in the best way arguing over that and cross-editing over and over? :) Annie 02:01, 17 November 2019 (EST)

(unindent) I think I see three separate issues here. The first one is whether COVERART titles should have language codes associated with them. I certainly see Christian's point, i.e. that works of art generally do not have language-specific information embedded in them. You could plausibly argue that we should create a "no language" code and add it to our list of supported languages. The ISO 639-2 standard, which we use as our guide in the language area, has a special code for it, "zxx - No linguistic content; Not applicable". It's a reasonable perspective and it has been discussed at length over the years.

At the same time, there is value to having language codes associated with COVERART titles. Consider Les Edwards, who was mentioned earlier. When you look at his Summary page, you can immediately see all the languages that his covers have been associated with, e.g. the cover of The 2nd Mayflower Book of Black Magic Stories was later used as the cover of the Polish magazine issue "Fenix, V4 #3, 1993". That's very useful data and the consensus of previous discussions was that its usefulness outweighs the "cover art has no linguistic content" argument. Personally, I agree with it, but, more importantly, it is the current consensus. As moderators, we must enforce it until and unless it has been changed. My job as a bureaucrat is to make sure that moderators follow the consensus regardless of their personal preferences. Please follow the consensus.

The second issue is the cover of Simulacron-3: Welt am Draht. The Note field reads "The cover art is credited and titled "The Last Elevator" on the copyright page." I don't recall coming across this scenario before. I'll need to read up on the history of the issue and think about it before I can comment further.

The third question is "language vs. country". Languages and countries can overlap, but they are very different animals. Consider the Kurdish language spoken by some 30 million people who live in a number of countries. Consider Telugu, spoken by over 80 million people. It's the 15th most spoken language in the world, yet there is no country with a Telugu-speaking majority. Consider Austria-Hungary, none of whose ethnic groups accounted for more than a quarter of the empire's population. Consider the Russian Empire, whose pre-WWI population was less than 50% ethnically Russian. Consider Belgium, Czechoslovakia, Yugoslavia. Heck, consider Southern Sudan with its 60+ ethnic groups. The list goes on and on.

Even countries with a single dominant ethnic group can have a thriving ethnic minority with a steady stream of publications in their own language, e.g. the Swedish minority in Finland. Emigre groups can publish books in their native language and try to ship them back to their country of origin, e.g. see this first edition (published in West Germany) of this Russian novel. Etc.

I am open to ideas and suggestions, but I don't think we can come up with a way to link languages and countries in a structured, database-friendly manner. Ahasuerus 21:35, 17 November 2019 (EST)

On Telugu (and all other languages pointed at here): The point I'm making is that language doesn't matter in viewing a piece of art (or listening to a piece of pure music), it is the culture that may matter (though in these times of global linking, it does so less and less). I am making my point from a German point of view: Here, the Turkish people are by far the biggest minority stemming from a foreign country. But they are as a whole no part of the Turkish culture anymore, they are also part of the German one (if they or German nationalists like it or not). The vast majority of the initial immigrants had planned to stay a few years and go back to their country of origin, but virtually no one did. And that's so because they are viewed there as Germans (this happens even between Austria and Germany, two countries seemingly culturally undistinguishable from outside of Europe). A book published in Turkish by a publisher situated in German may serve a) nostalgic feelings b) help educate people (based in the Turkish, German or any other language), c) reflect on the cultural differences (or commons) of cultures, d) serve the entertainment with any possible kind of cultural background). In this and any case mentioned above it is aimed at people living in the country of their choice (or maybe forced to live by circumstances). Thus, the country of publication is the first interesting thing for a given title, the title of the publication is the second. It seems you and me are interested in cultural diversification, and thus we would immediately be interested in a publication with a Cyrillic title published in the US. All of the titles (minus the artworks) would have languages assigned to them and are justly represented. Artworks don't rely on languages and would be represented by the country of the publisher and their title proper.
To assign a country to every publisher would be a huge task (the likes of which we are adjusted to, see the assigning of working languages to authors). On the other hand, I would estimate a number of 1,000 - 2,000 publishers (the 'big players') to capture the vast majority of reproduced art in a first step (for example ancient publications don't matter for this problem). Sounds manageable to me within a year or so. Christian Stonecreek 04:42, 18 November 2019 (EST)
I agree that there is a certain amount of value to knowing where a publication was published. Traditionally, librarians who use the MARC family of bibliographic standards captured "place of publication" information in field 260, subfield "a". At this time we capture it in our Publisher records' Note fields, e.g. "Based in Barcelona, Spain" or "Based in Stockholm as of 1975". We could try to make the way we capture this data more robust, e.g. by creating a separate Publisher field for "Place of Publication", but it would need a fair amount of design work and would likely be complicated: some books are simultaneously published in multiple countries, some publishers move from country to country, etc. Linking this information to Publication records would also be difficult.
Having said that, I don't see how changing the way we capture the "place of publication" information would affect the way we capture and display the language of COVERART titles. As I said earlier, location/country and language are different animals. "Place of publication" is a publication attribute while "language" is a title attribute. Linking them would be both difficult and against the way the ISFDB data is structured. Ahasuerus 13:02, 18 November 2019 (EST)
Well, the initial proposal was to drop the language for art titles altogether. And I see a general problem using functions of the title (here language) to point at publications that have no language assigned to them. Christian Stonecreek 23:51, 18 November 2019 (EST)
To go back to the original question, we do not record a piece of art, we record art used in or on a publication. I.m.o. the language of the publication is leading for the language assigned to the art title. No, the art itself may not have a language, the use of the art certainly does. Of course there will be borderline cases (multi lingual publications ets), but these are exceptions and should not be used to make a statement about this issue. I strongly disagree with the idea of dropping the language for art titles, and though the idea of adding a country field to publishers is nice, it would only lead to more confusion and pointless discussions as far a art titles are concerned. --Willem 07:05, 18 November 2019 (EST)
As you should be aware of this would prove quite difficult to fulfill, since publications have no language assigned to. It would have been possible in times where there was no more than one language in the database, but it is the multilinguality that makes things quite complex (even more when it used for cases that are not made out of one of its components). And if you would have looked into the Disch example pointed to above, you would have been aware of that problem. Christian Stonecreek 09:19, 18 November 2019 (EST)
As you should be aware of, 99.9% of all publications contain only writing in one language. You keep pointing out the few exceptions. I have looked at the Disch example above, and so what? Apart from other problems with that pub a unsourced dating of some poems, how many of those are in the database? --Willem 09:29, 18 November 2019 (EST)
Even for the multi-lingual books, we chose 1 language for the reference title and each book has a reference title. Having the cover art match that title makes this choice trivial and consistent and in line with any other book. If we are going to discuss languages and multi-lingual books, it is not the art we should be starting from, it should be the reference title. Because for some reason in the Disch example, it is the coverart that is the problem and not the container language. And that makes no sense. Annie 13:28, 18 November 2019 (EST)
Well, I should say it makes perfect sense. The container title is a COLLECTION, with English and German language on a par, but the poems were written in English and are the leading titles. And it is the container title that sets its language. Christian Stonecreek 23:51, 18 November 2019 (EST)
I would be against dropping the "language" attribute of coverart titles. Since others have already stated what I would state, I'll leave it at that. ···日本穣 · 投稿 · Talk to Nihonjoe 01:46, 19 November 2019 (EST)

'Add Artist' buitton

I'm trying to co-credit a second artist here but when I go to its Edit page, the 'Add Artist' button is not there. The coverart guidance doesn't seem to cover it. http://www.isfdb.org/wiki/index.php?title=Template:PublicationFields:CoverArt

What am I missing here? Thanks, Kev. BanjoKev 12:17, 15 November 2019 (EST)

The cover already exist and is used in more than one publication so you cannot change it inside of that publication. You need to go on the title level (here and edit from there). :) Annie 13:58, 15 November 2019 (EST)
Aha! Thanks :) Kev. BanjoKev 15:33, 15 November 2019 (EST)

Split publications outside of magazines

Apparently we need to open/reopen the discussion. My understanding of this had always been that IF a novel is split for publication in book form, each part is still called a novel, has its own title record that shows the split with disambiguation if needed and is varianted into the main title. See Dune for example. I asked about it early on and the help page explains split novels the same way - and the French tend to split a lot so we have thousands of those in the DB. I will try to find some of the old thread and update this message with them as well. However, the German publications seem to follow a different model: see this discussion and this example or this example - separate publication titles BUT all using the complete novel as a title (which under our way to record looks like a claim that the novel is printed inside of each volume in its entirety). That makes the DB inconsistent.

What is the current community consensus? We have 3 choices:
  • Stick to the rules - aka - separate titles, original type remains and then varianted up to the full work and fix all those German novels that are now out of compliance. Example - Dune above (the French titles, the Japanese ones and the Serbian ones for example).
  • The German model - I am not a fan of it because it makes it impossible to find what novels had been split without looking at all the publications one by one but if everyone likes it, then we can use it and then we need to convert half of our French books to use it (for example)... Example: the two German titles above.
Of course, if we go that way and the two parts of a novel have a separate translator, we will have an inconsistent DB.
  • Update the rule on SERIALS and make all of those split publications SERIALS regardless if they are in a magazine/fanzine or not.

Thoughts? Or am I misreading something in the different handling? We cannot do different things based on language - not on that fundamental level. Annie 17:50, 15 November 2019 (EST)

The last idea doesn't seem bad: as of lately there's the habit to publish portions/chapters of a NOVEL first as separate CHAP ebooks. Christian Stonecreek 02:23, 16 November 2019 (EST)
I have never liked the current approach of making something that is only a portion of the entire work a variant of the full work. Handling the situation as a SERIAL appeals to me. --MartyD 07:54, 16 November 2019 (EST)
Re: novels serialized as CHAPBOOKs, the data entry rules were changed to allow the use of the SERIAL title type in CHAPBOOK publications on 2018-11-29: The SERIAL title type is to be used when a work is serialized across multiple chapbooks.
Re: novels which are split into 2+ novel-length books when they are reprinted or translated, I guess there is another possible approach: keep the current VT method, but implement FR 1186, "Create a Title disambiguator field", and use the new field to document the nature of the relationship between the VT and the parent. I am not sure it would be ideal, but it's something to consider. Ahasuerus 11:23, 16 November 2019 (EST)
Why not just call those serials as well and be done with it? What’s the difference between splitting into 35K words chunks (chapbooks) and 45K words chunks (now it is not) and who is going to count? We kinda play it by the ear with the chapbooks on that updates rule (we know the Dune In 3 books is not a chapbook) but still - why keeping an artificial difference and have one more place where the type and behavior is based on word number? Annie 11:29, 16 November 2019 (EST)
We have been slowly expanding our use of the SERIAL title type, e.g. see the 2018-11-11 and 2018-11-29 changes in the Rules_and_standards_changelog. I guess we could expand it further and include "part of a NOVEL title which appears as a standalone NOVEL publications". The standard SERIAL naming conventions, i.e.:
  • If the title of a SERIAL part is unique, e.g. "Butterflies in the Kremlin, Part Eight: As the Bear Turns" or "Ciężki bój (cz. 1)", then use the full form of the title. If, on the other hand, the title is shared by at least one other SERIAL installment, append a space and a parenthetical statement such as "(Part 1 of 3)" to the title.
should probably work OK. Can anyone think of any issues that may arise? Ahasuerus 15:40, 16 November 2019 (EST)
Besides the cleanup effort that will follow - type change in all languages besides German, unmerges, renames and varianting for the German ones, I cannot see a harm in this approach. Not sure how we can catch those on a report so it will be mostly adhoc but at least we will stop having different practices across languages. Annie 16:27, 16 November 2019 (EST)
And if we are adding this, we probably should officially allow serials in collections and anthologies as well - no point having special rules for serialized stories there when any other serialized content goes under serials. And some people had been adding them this way anyway - some left over after magazine to anthology conversions, some intentional. Annie 16:37, 16 November 2019 (EST)
Pardon a focused perspective - So for L'île mystérieuse (Mysterious Island for the English title) - the first three publications (Parts 1, 2 and 3) would become SERIALs that precede the publication of the single compendium novel but variant to the same title record. Does the TITLE date change to the date of the full novel rather than the first part? And the translations of the parts become SERIALS that remain as variants to the full French title, rather than to the parts they correspond to. Which you couldn't do as you can't have variants of variants and makes sense for the two-part Romanian translation of 1979 which wouldn't have corresponding parts. There does not appear to be an Add New Serial under the Add New Data:, so how does one go about creating a SERIAL. Do you generate a dummy MAGAZINE with the various parts, variant them to provide anchoring links and then delete the magazine? Or create them as NOVELS and change the TITLE type? Or would changes be made to allow us to select the TITLE type when creating NOVELs, CHAPBOOKs and anything else we extend this SERIALization to? ../Doug H 20:03, 16 November 2019 (EST)
You add a chapbook with the SERIAL record instead of short fiction. :) Then the serial get varianted into the novel. The question of what we do with first publication date is good though - when the serialization is in magazines, we need a first book publication; when the first is in a chapbook, what do we want to do? Annie 20:28, 16 November 2019 (EST)
What if each portion of the serialization is novel length? Does it still go into a CHAPBOOK? Or would you create as a CHAPBOOK and then modify the publication to be a NOVEL? Would that leave the TITLE's title type as a SERIAL?../Doug H 11:04, 17 November 2019 (EST)
Just stop thinking of a chapbook as a container for a story. It is a container for one piece of fiction that cannot stand alone: SHORTFICTION, POEM, SERIAL. Serial does not have length - so can be used regardless of how big the chunk is. Same way how a Complete Novel inside of a magazine is still a serial :) Annie 11:43, 17 November 2019 (EST)
Rules state CHAPBOOK is a container for a SHORTFICTION, POEM plus ESSAY and INTERIORART. Putting a NOVEL in would require a change in the rules. The thread is about implications - there's one. ../Doug H 12:58, 17 November 2019 (EST)
But we are NOT putting a novel, we are putting a SERIAL. And we already allow that and have a lot of those (usually shorter but SERIAL is a SERIAL and we never put a limit on length officially) - see the change from last November. The software now allows a SERIAL as the piece of fiction in a chapbook (See the serialization here for example). If we had not updated the rules somewhere, please post the link where we do not have it and we should be fixing that. :) Annie 13:12, 17 November 2019 (EST)
This help is where I got the quote about CHAPBOOK, which does not include NOVEL (unnecessary as you pointed out) or SERIAL (as proposed). So the pub Vingt mille lieues sous les mers: Première partie will become a CHAPBOOK and the contained TITLE Vingt mille lieues sous les mers: Première partie becomes a SERIAL, and the title will move from the Variant Titles to Serializations under the Other Titles section of the Summary display for the base/full novel entry Vingt mille lieues sous les mers? ../Doug H 14:55, 17 November 2019 (EST)
Actually, that page also says: "SERIAL. Use for a title that would otherwise be either SHORTFICTION or NOVEL, but which is being serialized in a magazine, a fanzine or a series of chapbooks. Also use when a novel length work (40,000+ words) is printed as a single installment in a magazine or fanzine issue. Note that all newly added SERIAL titles need to be turned into variants once the original submission has been approved -- see Help:How to connect serials to titles for instructions.": (bold is mine). So we did update it for the case where it is chapbooks clearly and not volumes of a novel. But we do need to update the Publication_Type tab list. So I am posting a separate thread Annie 15:09, 17 November 2019 (EST)
Yep, that's the idea. The change that allowed it for actual serialization-in-chunks was recorded here, we need to update the help pages. Now the idea is to open it for any "published-in-chunks-in-separate-books". I will start a separate thread on the help page change. Thanks for checking the page. Annie 15:04, 17 November 2019 (EST)
I like this idea. I will gladly help cleaning up this mess, starting with The Green Mile, that one even has a boxed set of the 6 chapbooks defined as a novel :) --Willem 07:41, 18 November 2019 (EST)
Looking at Help:Use_of_the_SERIAL_type#Date_Rule, I see:
  • There is a deep and abiding divide between the way short fiction and novel length fiction pieces are cataloged by genre (and mainstream) bibliographers. When cataloging short fiction, the date of the original publication is always used as the "publication date" regardless of whether the original appearance was in a magazine, anthology, collection, or a chapbook. However, when cataloging novel length fiction, the date of the original serialization is not used and the date of the first book publication is used instead. This is an old (and arguably unfortunate) bibliographic convention, and we follow it.
  • This is the main reason why we have to display SERIAL appearances on the Summary Biblio pages: otherwise many (perhaps most) ISFDB users who are not familiar with this convention would never check the Title page and assume that the first appearance of Skylark was in 1946 etc.
  • The reasons for this divide are twofold. First, serially published novels are/were often extensively rewritten prior to book publication (e.g. the Lensman saga), so it's natural to think of these two versions as separate works. Second, the world of book collectors is somewhat removed from the world of magazine collectors. To a book collector, a "first edition" is the first book publication of the novel in question, not its first magazine publication.
  • The possible difference in content supports this rule, as does the desire to display, on summary pages, both the date of first serial publication and the date of first book publication (for novels) or first non-serial publication (for short fiction).
If we are going to start using the SERIAL title type for novels which were subsequently broken up into shorter novel-length publications, the reasoning cited above will no longer apply.
One possible approach would be to abandon this distinction altogether and use the same date rules that we use for all other title types. We would be breaking with the "old and arguably unfortunate" bibliographic tradition described above, but it would make our date data much more consistent and intuitive, especially on authors' Chronological pages. Granted, it would require a significant amount of cleanup since we currently have 13,298 SERIAL titles. We would also have to decide whether we use the date of the first installment or the date of the last installment as the date of the parent title. Ahasuerus 10:35, 17 November 2019 (EST)
But the dates of later serials are irrelevant for the first date of the novel. The case we are still looking at is serialized before first publication. The question is: if that first serialization is in chapbooks and not in magazines, do we keep the dates separate. Or am I missing something? Annie 11:53, 17 November 2019 (EST)
The approach that I described above would mean that the date of the parent NOVEL title would be the date of its first publication in any form, be it as a standalone edition or a serialization in any form. To use the Skylark of Space example above, the novel was first serialized in Amazing Stories in 1928. It was first published as a book in 1946. Under the current rules, the date of the parent NOVEL title is 1946. Using the approach described above, it would be 1928. The same logic would apply to serializations in CHAPBOOK pubs, NOVEL pubs, etc: the date of the first public appearance of a text would be the date of the parent title. Ahasuerus 12:13, 17 November 2019 (EST)
I got the idea, but above you said "If we are going to start using the SERIAL title type for novels which were subsequently broken up into shorter novel-length publications, the reasoning cited above will no longer apply.". And I was pointing out that it is not the novels subsequently broken up that are the problem for the dating rule. It is the ones that were originally published broken up (think the Victorians or all of the chapbooks and serialized works that are published these days pre-novel). Annie 12:46, 17 November 2019 (EST)
What I was referring to was the Help explanation that "the world of book collectors is somewhat removed from the world of magazine collectors. To a book collector, a "first edition" is the first book publication of the novel in question, not its first magazine publication." In other words, "magazines are one world and books are another world". The SERIAL data type was originally created to support the "magazine world" and it used "magazine world" rules.
However, once you start using SERIAL titles within CHAPBOOK publications and -- if this idea pans out -- NOVEL publications, the distinction becomes blurred. And if the walls separating the "magazine world" from the "book world" crumble, then you could argue that there is no longer a reason to have separate date rules. Just use the "first date of known public appearance" rule for all title records and be done with it. Ahasuerus 15:30, 17 November 2019 (EST)
It was the word "subsequently"(as opposed to "previously"/"pre-first complete publication") that my just awaken brain caught up on. We are on the same page here. :) Considering the blurring of the line between anthologies and magazines these days (half of the time, only the editor can tell you what they are publishing, especially for the ones coming once a year - and a lot of the current small-print magazines miss any letters or columns making them indistinguishable from an anthology series really besides the "issue #" on the cover), it may be worth looking into. Annie 15:46, 17 November 2019 (EST)
That's one of the dating rules that always tripped me - it ends up with variants published before the parent. I understand why it was adopted but... outside of the US magazines, I am not sure that the rewrite for the book really applied anyway. And we could have done something a lot more logical (on a parent, show two dates - first non-serialized and first serialized for example) instead of having a serial from 1956 showing in a 1960 entry. But them are the rules. I'd be happy to change them and do the cleanup if need be - but it is not mandatory in order to adopt SERIAL - we just need to come up with a non-magazine rule :)Annie 12:46, 17 November 2019 (EST)
Re: "on a parent, show two dates - first non-serialized and first serialized for example", a number of similar approaches have been proposed and discussed over the years. Unfortunately, each one ran into some "gotcha" or another, so nothing was ever finalized. It all went back to the original decision to handle magazines and books differently, which made things complicated. The current idea, if implemented, would address the underlying issue, and may be the most promising one yet. We'll need to think about it and, if we can't identify additional problems, post a cleaned-up version of the proposal on the Rules & Standards page. Ahasuerus 19:34, 17 November 2019 (EST)

(unindent) I am re-reading this discussion and it looks like we have two different (although complementary) data entry rules changes being proposed.

The first one is to change the way we handle "split novels", i.e. NOVEL titles which have also been published as 2+ novel-length books. The current rule as per Template:PublicationFields:PubType is to treat each individual sub-book, which I will call "segment" for the purposes of this discussion, as a NOVEL title within a NOVEL publication. The proposed new rule is to treat each "segment" as a SERIAL title within a NOVEL publication. An alternative version of the proposed new rule is to treat each "segment" as a SERIAL title within a CHAPBOOK publication. In both cases we also need to decide how to date the "segments" if they appear prior to the single-volume appearance of the main NOVEL title.

The second proposed change is to the rule which determines the date of NOVEL titles which were originally serialized. The current rule says:

  • when cataloging novel length fiction, the date of the original serialization is not used and the date of the first book publication is used instead

The proposed new rule is to use the date of the first installment of the first serialization of the text. An alternative version of the new rule would add the word "complete" before the world "serialization" since serializations sometimes die before they are finished.

I guess the first thing to do is to decide whether to post these two proposals on the Rules & Standards page as a single combined proposal or as two separate proposals. If we decide to post them as two separate proposals, then we need to decide which one will be posted and discussed first.

The main advantage of posting them as a single proposal is that it would present a comprehensive self-contained solution to the various SERIAL issues that we have been dealing with for years. It may also make the cleanup easier since we would only need to do it once. The main disadvantage of doing it as a single proposal is the complexity associated with changing a bunch of rules at once. We may miss some important caveat if we make the proposal too complex. Ahasuerus 19:11, 20 November 2019 (EST)

One by one with a delayed execution on cleanup if approved until the second one is also resolved? Noone says that we need to go and start cleaning up ASAP...
About the novel vs chapbook - if we decide to go with SERIAL title in a NOVEL publication, we will need software changes:
  • EditPub, ClonePub and Import will need to allow a novel with reference title as a serial
  • The show pub will will need to be updated to account for the serial as a reference title.
  • Probably some things I had not thought of...
And then we are getting into the counting conversation again - if a book is split into 4 80-pages chunks, are those chapbooks or novels? What of it is in 2 130 pages one and one last 40 pages one? 3 110 pages ones? Where do we draw the line between a chapbook and a novel as Serial publications and who is going to do the counting? While with novella/novel it makes a difference, with the split novels, it really does not matter for anything anyway. Using the same container for every serial will clear all that out. And we already use chapbooks for serials. So... :)
If the problem is the name, we can always rename that to "ISFDB container" and be done with it... Annie 21:57, 20 November 2019 (EST)

Linking to outside websites

Has there been any progress in allowing ISFDB publication records to be directly linked to other websites? Mhhutchins|talk 15:24, 16 November 2019 (EST)

FR 957, Add a repeatable "Web Pages" field to Publication records, was discussed in late 2016 and had broad support. It hasn't been implemented yet. Ahasuerus 15:43, 16 November 2019 (EST)
I would think that if you want this database to be a resource for people other than those who edit it that making linkable records would be a priority. Mhhutchins|talk 02:25, 21 November 2019 (EST)
Done. Ahasuerus 20:07, 27 December 2019 (EST)
Awesome! ···日本穣 · 投稿 · Talk to Nihonjoe 21:19, 27 December 2019 (EST)

Help page update: Chapbooks and Serials

When we allowed the SERIALS to be the fiction piece of a chapbook (See the changes log, we updated all explanations of what a Serial is but not of what a chapbook is. The places I can find are:

Did I miss any? We need to add SERIAL to the SHORTSTORY and POEM in these write-ups. Any other places or any concerns? Annie 15:16, 17 November 2019 (EST)

There is also Help:How to convert a novel to a chapbook. It needs to have POEMs added and generally cleaned up. Ahasuerus 17:18, 17 November 2019 (EST)
Ah, yes. The page that also says "If a publication has been primary verified, it should normally not be converted from NOVEL to CHAPBOOK without consulting, or at least informing, the primary verifier.". A part ignored way too often. (and moderator note would be enough of a notification as there is always at least one EditPub needed). While we are changing this page, should we add this as a viable notification method for that in the relevant sections and in the warnings at the bottom? Annie 18:01, 17 November 2019 (EST)
That page looks like it could use a lot of TLC. It was created a long time ago and a lot has changed since then. It's probably better to clean everything up and re-evaluate afterwards. When I was upgrading other old Help pages 1-2 years ago, I found that so much got changed or dropped in the process that it made sense to wait until the end of the cleanup phase before adding anything new. Ahasuerus 19:27, 17 November 2019 (EST)

(unindent) Basic cleanup done; references to POEMs and SERIALs added where appropriate. Ahasuerus 17:42, 19 November 2019 (EST)

Night's Dawn Trilogy (paperback) series

Can someone look at this one. Why do we have it as separate title series when all the contents are the half novels of the main series? It is just the format that is different - the first 2 are the complete first novel and so on - they are not split in different places? How is that different from the French translating a novel into 2 volumes? And if the first volume from the main series is printed in 2 volumes in Russian (matching the paperback release series) and the second in 3 (splitting differently and using the original as a base), where do the translations get connected? In different series? Or in the main one even if the first volume matches the split of the second series?

Under the current practice, they should have been varianted to the full novels (as we do for split translations) - the way they are done here not only splits the whole series weirdly but also loses the connections between the different works and also introduces a third way to record a split novel. So why do we have it this way? Does anyone remember? I will be pinging all the active PVs as well to see if any of them has an idea as well.

I really do not like varianting half novels to the full novel with both still being novels but this is what we do. Just because these are in English does not make the rule different, does it? Or am I missing something? :) Annie 16:35, 17 November 2019 (EST)

It turns out that there is at least one other series that uses a similar approach -- see Woman of the Iron People and its "(split paperback edition)" sub-series. I don't know for sure, but I suspect that the editors who originally organized these series wanted to avoid using VTs. Regardless of their motivation, I don't think it's the correct approach under the current rules. In addition, using "paperback", i.e. an attribute associated with publications, to organize title records only confuses things. At one point we did it to distinguish between paper-bound and electronic versions of certain magazine runs, but it was the last resort. Ahasuerus 17:37, 17 November 2019 (EST)
There are at least a few more I suspect... The magazines are also a mess (we had a thread earlier... I need to resurrect that and really deal with the that split - especially now when we can show format in the grid) but I hoped that at least the novels are sorted out. Then I started looking... Making up your own rules that contradict the written ones (which you do not like) is so not the spirit of this project... :) I can see their point BUT if Dune, volume 1 in French, Serbian or Japanese goes under the main title, an English split goes there as well (and so is the German in the other discussion we are having). Otherwise we just make a mess of a page and noone knows what contains what... Organizing the omnibuses into their own subseries - fine. Splits? Do we make separatem series for "published in 2 parts each", "3 parts each", "4 parts each"..."12 parts each" (now that is a serial but...) :) Annie 17:51, 17 November 2019 (EST)
One more Outremer Universe. Not even a note how the one series connects to the other (1 into 2? New split?). Annie 17:55, 17 November 2019 (EST)
It looks like the "split" information was added at the title level. Ahasuerus 19:23, 17 November 2019 (EST)
Of the split volumes - which makes it more or less invisible unless you know to look for it... And if you look only on the publication level, there is no indication at all of what that is. Annie 19:38, 17 November 2019 (EST)
And there is Varney the Vampyre but someone needs to write some notes explaining what is split and why and how they connect... Annie 17:55, 17 November 2019 (EST)
My best guess is that Varney the Vampyre (Wildside split) was moved to a separate sub-series because the 5 constituent volumes had individual titles as opposed to "Varney, the Vampyre or, The Feast of Blood, Volume I", "Varney, the Vampyre or, The Feast of Blood, Volume II", etc. This is one area where allowing SERIAL title records in NOVEL publications -- as discussed above -- may help. I would suggest that we wait for the outcome of that discussion before we make any changes to the series listed above. Ahasuerus 19:23, 17 November 2019 (EST)
Agree - I am not touching any of those series and variants until we decide what we are doing.
PS: Or we can just say that SERIALS mean chapbooks regardless of lengths (instead of changing a Novel Pub to allow two types of content - one native and one SERIAL - NOVEL is a container and a type rolled into one so we do not have a NOVEL container-only to add a SERIAL to. We can change all that of course but using the chapbooks will not require code change. And counting of words in a SERIAL... Allowing SERIALs in NOVELs is... complicated :) Annie 19:38, 17 November 2019 (EST)

Simon Stålenhag: The Eletric State - "Graphic Format" or not?

I' going to enter the German edition of the extensively illustrated The Eletric State by Simon Stålenhag and wondering if it's "Graphic Format". The help says that for a "Graphic Format" it is required that "graphic material is inseparable from the text". However, in this case the text is always separated from the illustrations, but there are definitely a lot more illustrations than text (approx. 100 pages with illustrations and 42 pages with text). Do we have an unwritten rule that still makes something like this "Graphic Format", just because of the majority of pages with illustrations? If not I'd leave that checkbox off and add some information to the note.

Jens Hitspacebar 13:26, 19 November 2019 (EST)

I am not aware of anything like that. If the text is effectively unchanged even if you remove all of the illustrations, it's not a graphic novel. Ahasuerus 17:32, 19 November 2019 (EST)
I agree. Heavily illustrated books are not graphic format in my book. Otherwise half of our juvenile very young fiction will need to be marked that way. :) Annie 20:09, 19 November 2019 (EST)
That's what I thought as well, thanks for the clarification. Jens Hitspacebar 12:32, 20 November 2019 (EST)

Vladimir Colin Award

(Copied from my talk page, Stonecreek 01:58, 20 November 2019 (EST)):

Hi, I wanna add this award on Isfdb but I don't know how... Here is about a drop-down list with all of the award types known to ISFDB, but Premiul Vladimir Colin (Vladimir Colin Award) isn't on the list. Abația trilogy was received Premiul I Vladimir Colin (info here) in 2006.--Terraflorin 00:54, 20 November 2019 (EST)

I have add some information here on my user page. --Terraflorin 05:43, 20 November 2019 (EST)
Looks good to me. Probably should add it as a polled award (as this is the only way to show the top 3 properly). As for the process: It is one of the tasks we need a bureaucrat for. Ahasuerus usually gives it a few days to see if there are objections and then creates the awards if there are no issues with them. So give it a few days here for the process to work through. :) Annie 10:48, 20 November 2019 (EST)
It certainly looks like a legitimate award, but there doesn't appear to be a lot of high quality information about it online. Will we be able to identify all nominees and winners? Ahasuerus 15:28, 20 November 2019 (EST)
Any ideas/suggestions? Ahasuerus 15:37, 2 December 2019 (EST)

Misdated titles: new cleanup report needed

Under the current rules, there is only one case where we will have a title dated earlier than its oldest publication (when the title has a publication attached to it (this will exclude all parent titles with no pubs for now) - when we do not have this first publication in the DB.

Technically, in this case adding that first publication is always the best solution although there may be a case where we may want to just note it.

Can we have a new cleanup report so we can start clearing these misdated titles from the DB? As I expect a pretty big number and a lot of work on the text types (novels and stories and essays first publications missing), maybe we should start with the two art types - these should never pre-date their publications. Then slowly add the text ones (with ignore being possible if we decide that we can have a text title here dated per first publication but not add the first publication.) Thoughts? Annie 15:11, 21 November 2019 (EST)

I agree. That would be a better cleanup report than the one I was thinking about (variant dated on the same date as the original). Ignore is indeed necessary. A lot of titles will have a title note explaining where and when the title was first published, and for various reasons the publication can not (yet) be in the database (think of fanzines, newspapers etc.) --Willem 15:31, 21 November 2019 (EST)
This one will also be catching things like: Book added before publication and then delayed - and whoever fixed the pub forgot about the titles (especially the coverart one). Or a non-existing edition is deleted from the DB but dates on the titles remaining were not adjusted. Or interior art dated with the date of the original cover it represents. Unmerges where one does not pay attention to the resulting dates (pulling the first edition out will leave both the new and the old title with the same date). And so on. Mistakes happen. It will help us solve the immediate known issue with the misdated variants (both from the coverarts rules misunderstanding and the non-fixed ones from the very old "record variants with the date of the original" days but it will also be useful long term. :)
Once we get these sorted, we can think on the "titles with no pubs which do not have variants (which are excluded from the "titles with no pubs" report) :) Annie 15:51, 21 November 2019 (EST)
Checking the database, I see 4,534 COVERART titles whose 4-digit years are before the 4-digit years of their first publication date. There are another 10,000-ish COVERART titles whose 4-digit years match, but the months/days are before the first publication date. Many of them are presumably dates with no month/day information, so the report logic will need to skip them and possibly other stuff. If we start with the 4,534 titles that are more or less straightforward, it should hopefully take care of the low-hanging fruit.
Here is what the rest of the title types look like (year mismatches only):
+--------------+--------------------+
| ANTHOLOGY    |                287 |
| COLLECTION   |                821 |
| COVERART     |               4534 |
| INTERIORART  |              22763 |
| EDITOR       |                 11 |
| ESSAY        |              10717 |
| INTERVIEW    |                455 |
| NOVEL        |               6203 |
| NONFICTION   |                327 |
| OMNIBUS      |                171 |
| POEM         |               6222 |
| REVIEW       |               1896 |
| SERIAL       |                 73 |
| SHORTFICTION |              39750 |
| CHAPBOOK     |                397 |
+--------------+--------------------+
Ahasuerus 17:02, 21 November 2019 (EST)
| EDITOR | 11 |
Can you post these 11? These are most likely editors where the date is not adjusted to 00-00 after making the yearly record. We may as well get them all cleared. The Serials should also be easy to cleanup so if you can post the Title IDs, I can take care of them. No point waiting for an official report for such small numbers. Annie 21:15, 22 November 2019 (EST)

(unindent) Sure thing. The EDITOR title IDs are: 

+----------+
|   854745 |
|   522441 |
|  1421614 |
|  1565713 |
|  1571347 |
|  1591529 |
|  1839076 |
|  2006082 |
|  2073825 |
|  2454644 |
|  2599718 |
+----------+

A cursory review suggests that they are a mix of different types of issues. In the meantime, FR 1323, "Cleanup report to find titles whose dates are before the first pub date", has been created. Ahasuerus 10:40, 23 November 2019 (EST)

Link Publication pages back to the submission which created the publication record

It occurs to me that it should be very easy to add a "View original submission" link on Publication pages. The link would take you to the submission which created the displayed Publication record. I can't really think of a reason not to do it, but there are a few caveats to keep in mind:

  • The link would only be available for publications created after 2016-10-24, the date when we started capturing this information in the database
  • Only the original submission would be linked; other submissions which have affected the displayed publication since it was created would not be linked because the linking data is currently not available

Also, I wonder if we may want to display the proposed link only if the user is logged in. For casual users without ISFDB accounts it may be meaningless clutter.

What do you think? Ahasuerus 17:42, 21 November 2019 (EST)

I vote for showing it only for logged in users (and even making it a preference at some point even for logged in users).
Even if we do not have the complete history of the publication, knowing the original editor (and the original handling moderator - as view_submission has that as well) gives you two (or one...) name(s) of people that had done some research on the book to ask questions to. Plus all the notes the original submission had for the moderators. And we already can find that in the Recent Edits anyway - it just will take a long time to find it. :) Annie 18:03, 21 November 2019 (EST)
So the original submission link should show the original information? Not the current value of the fields like the current changed pubs report does? I would still see value to showing a history page of all edits (even if the edits only show the current information). Sometimes I want to know who last changed a pub and trying to work back through the edit history is a pain. -- JLaTondre (talk) 18:54, 21 November 2019 (EST)
Here is an example of what is in the "First" submission. Since then, the external ID had been shifted and the number of pages cleaned. So if I am reading your question correctly then yes, we will see exactly what was submitted in that initial call. The Edit ones are tricky (as we do not save status) but the creation ones are very useful. Annie 13:14, 22 November 2019 (EST)

(unindent) There is a significant amount of history here. Let me take a step back and cover some of it.

Ideally, we would want to have complete "Publication History" snapshots of all Publication pages available to editors. Each snapshot would display what the Publication page looked like prior to each change. It would be similar to the way Wikis let you view the history of each page. This functionality was first requested in 2006 -- see FR 43, "Edit History".

The problem with that FR is that the ISFDB database, unlike Wikis, has a lot of different types of records: titles, authors, publisher, series, etc. They are all interrelated. Changing a title record, an author record or a publisher record can change the appearance of dozens, possibly even thousands, of Publication and other pages. For this reason recreating what each Publication page looked like at various points in the past is a much bigger can of worms than what the software responsible for generating Wiki-based "history" pages has to deal with.

We have considered a number of different approaches over the years. The original approach, which Al von Ruff began implementing ca. 2007, vastly underestimated the complexity of the task. Eventually that functionality was disabled. Since then two workable approaches have been identified. The first one is to take a snapshot of the Publication page of each primary-verified publication before an Edit Publication submission affecting it is approved and save the snapshot in the database. (The reason this functionality is supposed to be limited to primary-verified publications is the amount of disk space that it takes to save the HTML of a publication display page.) These saved HTML snapshots would then be made available to editors as partial "edit history" for each PV'd publication. A certain amount of development work has been done in this area -- see SR 173 -- but much remains to be done.

The second approach is to implement FR 1238, "Create an Edit History page for publications". It's more limited in scope: it simply creates a list of "New Publication" and "Edit Publication" submissions related to each publication record. As we all know, once an ISFDB submission has been approved, the "before" state of the database is no longer available, so it's not a complete snapshot, but it's better than nothing.

The problem with the second approach is that our submission history currently stores Publication IDs in a way that makes it impossible to find them programmatically. It does, however, store newly created publication IDs in a way that makes it possible to find them easily. In order to implement the full functionality requested in FR 1238, we'll need to modify the software to store affected Publication IDs in a different way and then convert a couple million submissions currently on file. It's somewhat easier to implement than the first approach described above, but it still requires a fair amount of work.

What I am proposing here is to go after the low-hanging fruit first. We already have the ability to link each Publication page to the submission which created it. It would take no more than an hour or two of work to display links back to the originating submissions on Publication pages. It's not a whole lot, but it's better than nothing and it's something that I can realistically do even in my current state. Ahasuerus 16:35, 23 November 2019 (EST)

Anything you can provide will be appreciated as always. But it won't stop us wanting more ;-) Please don't ever take our requests, suggestions, and comments negatively. We (I believe I'm not speaking for myself) recognize that you're a volunteer as well and owe us nothing. We appreciate the work you put into keeping this site going. -- JLaTondre (talk) 10:12, 24 November 2019 (EST)
Thanks, I appreciate the understanding! If I sound frustrated at times, it's only because my productivity has been so much lower lately. Ahasuerus 08:13, 25 November 2019 (EST)

Login issues and notifications

I couldn't login to isfdb because I recorded the username I entered when I created the account, but failed to notice that isfdb had automatically changed it by capitalising the first letter. Once I realised that, I was able to login to both the wiki and the main page.

However, despite the note on the results page about a successful account creation and login: 

 Login successful
 A confirmation code was sent to your e-mail address. This code is not required to log in, but you will need to provide it before enabling any e-mail-based features in the wiki.

 Welcome, Lukekendall!
 Your account has been created. Don't forget to change your ISFDB preferences.


I have not received a confirmation code - even now, about 8 hrs later. I also checked my spam folder and there was nothing from isfdb there. —The preceding unsigned comment was added by Lukekendall (talk • contribs) .

We really need to fix that wording... ISFDB does not send a confirmation code - we had been having so many issues with them that we just disabled them and the only mail-based function we have is the ability to send a mail to another editor who also has a mail anyway :) You are all set to start editing. You already have access to the DB (you will not see the changes immediately because we are a moderated system -- so a moderator needs to approve your request (and work with you if there are issues) and you can post on any Talk page in the wiki. Posting on non-wiki pages (such as your own wiki page) requires you to first have a few posts on Talk pages (anti-spam measures). Welcome to the DB! Annie 10:50, 22 November 2019 (EST)
Thanks, Annie, understood! Lukekendall 07:21, 23 November 2019 (EST)
Checking the software, I see that the misleading notification is displayed by the Wiki software. Unlike the core ISFDB software, which we have full control over, our Wiki software is a third party program. I am not an expert, but I'll take a closer look to see if the message can be customized. Ahasuerus 00:10, 2 December 2019 (EST)

Novellas and serialization in chapbooks

The split novel rule we are talking about up higher is just for novels. But we do have split novellas as well. Any reason/rule that stops us from actually treating these as proper serials even if they are not in a magazine? Here is an example - if this is a novel, this would have been the correct way to do it. Or what do we want to do here? Thoughts? Annie 11:58, 22 November 2019 (EST)

I think novellas serialized in multiple CHAPBOOK publications should be treated like novels: individual "segments" should be entered as SERIALs.
As an aside, the linked book is available online. After converting the HTML to TXT, I see that the word count is 72,890, so it's a NOVEL according to our rules. As we discussed a few years ago, the Russian word повесть (povest') doesn't map neatly onto the English word "novella". In modern Russian it's mostly (although not exclusively) used to indicate that the work's structure is not as complex as that of a typical novel. Hence 80,000-word and even 100+K-word "povests", which we would treat as NOVELs for our purposes. Ahasuerus 12:25, 22 November 2019 (EST)
Well, novels segments are now novels, not SERIALS :) But I got your point.
As for the Russian "повесть" vs "роман"... We will have the same problem across the whole Eastern block and we are adding a lot more of them lately. The definition of these never included length. And Russian also has "новелла" (novella) which is synonymous with a short story actually :) But we are now going into the counting game again and in an even harder case because of the alphabet.
I will be more than happy to convert that one to a novel (it was on my list to check - 300 pages on that first edition did look a bit too long for a novella) - but we probably need a better way to determine that. International projects are fun, aren't they? Annie 12:53, 22 November 2019 (EST)

Thanksgiving holiday in the US

This week (on Thursday) is the Thanksgiving holiday in the US, so people (like me) might be slower to respond than usual. Then there's Black Friday, where insane people go crazier trying to find great deals at stores on Friday (I generally avoid this one). So, patience all around. (^_^) ···日本穣 · 投稿 · Talk to Nihonjoe 16:58, 25 November 2019 (EST)

Adding the Australian national library as an External ID and a template

An editor mentioned it and I went digging. They do have a persistent identifier (https://nla.gov.au/nla.cat-vn6978328 for example where the ID is 6978328 (https://catalogue.nla.gov.au/Record/6978328 also seems permanent but if you click on permanent link, you get the above so we probably should go for it). So can we add it? Annie 21:11, 25 November 2019 (EST)

I would support that. ···日本穣 · 投稿 · Talk to Nihonjoe 12:18, 27 November 2019 (EST)
I have poked around a bit and the IDs do look stable. I see no reason not to add them, but I seem to (vaguely) recall that we had this discussion a few years ago and it petered out. I've had no luck finding the discussion using Google Search. Would anyone happen to remember any details? Ahasuerus 12:20, 27 November 2019 (EST)
I have vague memories about discussing and deciding not to add it in the first batch due to the relatively low number of entries we had in the system and the much bigger fish we had still standing. Will see if I can find the thread later today. Considering that we have the British and US equivalents and we are an English language site, I’d say that even if we have only a few, we need it. And maybe that will drive more books from down under into the DB. That makes me wonder about the CAnadian library. :) Annie 13:33, 27 November 2019 (EST)
OK, if there are no objections, I will create the new External ID/template pair in a couple of days. Ahasuerus 16:20, 27 November 2019 (EST)
FR 1324 has been created. Ahasuerus 12:41, 30 November 2019 (EST)
Done. Ahasuerus 15:36, 2 December 2019 (EST)
Thanks! We have 71 links with the Record format and one with the cat-vn one which I will move probably next weekend. We also have some links to NLA that lead to a page that requires a user to be logged in so I will look at all NLA references we have and clean them up (and probably come and ask if I cannot). Annie 16:32, 2 December 2019 (EST)
Can we rename that from ANL to NLA? It is usually referred to that way. Not critical but may be good to match how people look for it... :) Annie 17:09, 2 December 2019 (EST)
Done! Sorry about that, my bad. I have also added the new templatw to Help:Using Templates and HTML in Note Fields. Ahasuerus 19:00, 2 December 2019 (EST)

Del Rey Ballantine

Six publications are using Del Rey/Ballantine. As there's no note explaining why that publisher exists I suspect they are in error and should have been using Del Rey / Ballantine? --Marc Kupper 23:05, 26 November 2019 (EST)

I’d agree. We have only 2 PVs there so I would say to just leave them a note and fix that. Annie 23:22, 26 November 2019 (EST)
Thanks - plus I ran across Template:PublicationFields:Publisher which says "The things we want to avoid are the Imprint/Publisher (with no space) ..." --Marc Kupper 16:37, 27 November 2019 (EST)
Yep. If there is a reason, there should be a note explaining why. This seems like an oversight. Annie 17:53, 27 November 2019 (EST)
Is there anyone objecting a merge of the two publisher records? Last call :) Annie 19:38, 4 December 2019 (EST)
Publishers merged, the only PV in the incorrect one had been notified and we have one less mistake in the DB. Onto the next one. Annie 11:58, 12 December 2019 (EST)

French Perry Rhodan series

I have a question about the French Perry Rhodan series, for example Rhodan renie Rhodan. Isn't this an omnibus, when two German titles Guckys große Stunde and Atlan in Not are put together in one pub? --Zapp 15:01, 28 November 2019 (EST)

Collection or an anthology (depending on the authors) actually because the originals are novellas and not novels. But yeah - this looks weird - if these are indeed the same texts, these should have been added as collections - the same way every Foundation out there is a collection despite what national publishers may think. I wonder if the German ones were not novels before (I remember a lot of those being converted a few years ago) and the French ones were never changed (and were added as novels based on the split novel rules (in reverse) - which say that part of a novel is a novel - still weird reading of the rules but at least it makes some sense). Linguist is around - so why don't you post on his page and see what he knows about this? Annie 15:17, 28 November 2019 (EST)
Hi. Hauck had devised this "Perry Rhodan in French" series, on the ground that at a certain time, Fleuve Noir started compiling two original episodes in one volume (usually novellas), presented as a single novel. Sometimes the novels are divided into two parts with individual subtitles, but sometimes not, and in this case there is no visible separation between the two episodes, and of course no French titles to variant to the German ones (this is usually indicated in the notes). Hence his choice, which I went along with. It is true that it is annoying not to be able to link the French translations to their originals, but there it is. Making collections or anthologies of them (and varianting the parts) would be possible for some, but not for all of them, which I think would wreak havoc in the series if it were attempted. But someone might have a bright idea to solve the problem… :o) Linguist 05:24, 30 November 2019 (EST).
Part of the problem also seems to be that Darlton & Scheer are credited as authors / editors and not the actual authors of the respective novellas, or are they somewhere in the volumes? Christian Stonecreek 12:09, 30 November 2019 (EST)
It would be in theory possible to identify the beginning sentences of the respective novellas, enter them (likely as by 'uncredited'), and then variant them to their parent titles, but I think you'd need both the originals and the French publications for that. And it still seems possible that the latter are in fact fix-ups with linking material by the French editor(s), analogous to the work done here. Christian Stonecreek 05:51, 1 December 2019 (EST)
Late editions do credit the actual authors (particularly after Presses Pocket took over the series), but this doesn't solve any problem : take Projet Basis and La déesse endormie for instance : they correspond to the first and second half of Perry Rhodan Silberband #101, i.e. Eiswind der Zeit, revised version by Hubert Haensel of 10 German episodes individually credited on copyright pages to H. G. Ewers, Kurt Mahr, Hans Kneifel, Clark Darlton or H. G. Francis. The first French volume is just divided into 16 chapters, and no individual titles. The second one has 13 chapters, with five subtitles corresponding to the titles of the original German novellas : so from one book to the other, the presentation is different, and makes systematic varianting to original titles and crediting to real authors impossible. Ein echtes Durcheinander ! Linguist 05:54, 1 December 2019 (EST).
Well, no doubt about that! At least for the moment, for me also it seems best to leave the series as it is. Christian Stonecreek 06:33, 1 December 2019 (EST)
Or we can fix at least the ones where the separation is there and clear enough. While that won't catch everything, it will catch the ones we can catch and be more consistent with the intent of the DB. Not sure how easy that would be if we do not have access to a lot of the issues though... Annie 06:44, 1 December 2019 (EST)

Wording of text printed by "Incomplete" template

It just occurred to me that the text "Contents incomplete" printed by the "Incomplete" template could be ambiguous for some users: it can be interpreted as "contents in the publication are incomplete" (e.g. a misprint) or as intended as "contents in the database not completely entered yet". Shouldn't the wording be expanded a bit to make it's meaning clearer? E.g.: "Contents of this ISFDB record are incomplete" Jens Hitspacebar 10:47, 30 November 2019 (EST)

I may be having a slow evening (or morning...) but what would "contents of the publication itself is incomplete"? Contents table? Something else? Annie 06:02, 1 December 2019 (EST)
What I mean is that, for a casual user who doesn't research our wiki for more information about it, the phrase "Contents incomplete" could refer to either the database record or the book. We, as editors, know what we mean: the database record is incomplete. But a casual user reading this phrase might think that we mean the book instead and then ask himself "aha! But what is incomplete in the book? The contents table, or what?" or "is it a misprint, or what in the book is incomplete". In short: the phrase ambiguous. Jens Hitspacebar 08:41, 1 December 2019 (EST)
<light bulb> I think I see what you are referring to. I remember Keith Laumer once complaining about his Swedish publisher "abridging" one of his novels by dropping the last couple of chapters. I also recall a magazine editor dropping the ending of one of Philip K. Dick's novels. And, of course, printers occasionally screw up, which results in missing pages in the final product. Is that what you mean? Ahasuerus 15:46, 2 December 2019 (EST)
This makes sense (Bard did the same to Zelazny's "Lord of Light" first Bulgarian edition - they 'forgot' to print the last chapter). And now that you pointed it out, I can see how "Contents incomplete" can be read that way as well. Maybe we should go even further than that: "The contents of this ISFDB record is incomplete and additional eligible content still need to be added". Or words to that effect (proving again that templates are good things) :) Annie 16:43, 2 December 2019 (EST)
Yes, that's what I was referring to, especially the "printers occasionally screw up" part :) I hadn't thought about abridgements yet, but now as you mention it: yes, that's also a way to "misinterpret" the "Contents incomplete" phrase. Actually, extensive abridgements of translations were very common in German SF publishing at least until the late 1970s. It's quite possible that some users assume that "Contents incomplete" refers to these abridgements. Jens Hitspacebar 18:32, 2 December 2019 (EST)
OK, we are on the same page then.
Re: Annie's suggestion, I think "additional eligible content[s] still need to be added" would be too limiting since the "Incomplete" template may be used when we have no plans to add more titles, e.g. when entering a non-genre anthology. Something like "This publication contains additional titles which have not been entered into the ISFDB database" would be hopefully generic enough to cover all possible permutations. Ahasuerus 16:18, 3 December 2019 (EST)
I disagree. So did you a few weeks ago. See this and FR 1309. We specifically created this template for cases where we still want to add more contents. We need another one for the non-genre things - mixing the two makes this one useless (the whole point of having it is to ensure that we can find the magazines/anthologies that NEED more contents. Annie 16:24, 3 December 2019 (EST)
I agree with Annie. The template's help states that is is "to be used in publication notes to indicate that not all eligible title records have been entered yet. Not supposed to be used if ineligible (typically non-genre) titles are intentionally excluded." Her proposal for the template's text is good. A new, different template for omitted non-genre titles, e.g. {{IneligibleContentOmitted}}, is a good idea. Jens Hitspacebar 16:38, 3 December 2019 (EST)
Oh, I see. Sorry, I was confused. I'll go along with Annie's suggestion then, perhaps modifying the wording a bit, e.g. "The contents of this ISFDB record are incomplete; additional eligible titles still need to be added". Ahasuerus 17:13, 3 December 2019 (EST)
Massage away -- it was first attempt at saying what would make the most sense. Maybe "contents listed in this" instead of "contents of this"? So it is clear we are talking about the contents below. Or am I overthinking it? :) Annie 18:05, 3 December 2019 (EST)
Something concise and explicit like "The Contents section is incomplete; additional eligible titles still need to be added"? Ahasuerus 20:11, 3 December 2019 (EST)
Is that unambiguous enough to ensure that it is clear we are talking about our contents section and not the book's? Maybe insert "below" after section? Or "of this record"? Annie 20:42, 3 December 2019 (EST)
I like "below". And, as you said, we can always change the wording again because it's a template. Ahasuerus 23:18, 3 December 2019 (EST)
There should definitely something like "below" or "of this record" in the wording, otherwise "The Contents section" would still be a bit ambiguous, because it could still be interpreted as referring to the book's contents section I'd prefer "of this record" because, unlike "below", it doesn't create a "dependency" to how notes and contents are displayed. If the display of the notes and contents ever gets a massive redesign, or an app is created, "below" could become the wrong hint if the template's wording is forgotten to be adjusted as well. But as that'd be easy to fix I'm fine with "below" as well :) Jens Hitspacebar 03:39, 4 December 2019 (EST)
OK, I see what the problem is. Let's go with "The Contents section of this record is incomplete; additional eligible titles still need to be added" them. Ahasuerus 11:17, 4 December 2019 (EST)
Sounds good. Jens Hitspacebar 13:39, 4 December 2019 (EST)
FR 1325 "Change the wording of the 'Incomplete' template" has been created. Ahasuerus 16:44, 4 December 2019 (EST)

Wording of text printed by "Incomplete" template - Outcome

The wording of the "Incomplete" template has been changed to "The Contents section of this record is incomplete; additional eligible titles still need to be added". Ahasuerus 16:33, 5 December 2019 (EST)

Rudimentary "Edit History" implemented

As per this discussion, a rudimentary "Edit History" system has been implemented. At this time it is limited to submissions which have created new publication records since 2016-10-25. Publication pages have been modified to display "[Edit History]" links which take you to the new "Publication History" page. Note that only publication records have been affected and that only NewPub, AddPub and ClonePub submissions are currently displayed. It's not much, but it should help in certain cases. Ahasuerus 20:37, 1 December 2019 (EST)

Thanks - that can come handy when chasing why some things look the way they do :) Annie 01:14, 2 December 2019 (EST)

Titles and images for interior art

I've acquired a number of art books/calendars for artists of record on ISFDB and was checking to see if they were used for covers. For calendar matches, I simply added a note to the title record for the cover. Then I noticed that some interior images were given titles not in the book, and multiple publications used the same interior image title record. I presume someone had access to both books, but for someone working from a single book, the naming would be impossible without stored images for the artist.

Some interior images are stored (e.g. Map of Compact Space) although I suspect such usage is obscure. What is the current stand on ISFDB's ability and desire to store interior art images? (I'm not looking for a change, just a statement/comment, since searches of the Help provide little information beyond mention of the example above.)

P.S. Actually searching such images to find a match for an image in hand would have been unthinkable when we first started loading images, but given what Facebook (and others) are doing, it may not be long before someone could upload an image and search for matches. But I digress. ../Doug H 23:10, 1 December 2019 (EST)

As an aside on the last paragraph: Well, Google has Image search which accepts either a link or an uploaded image. And occasionally it does help with the identification of uncredited covers for me (enough to know where to look to find the original anyway). Annie 01:12, 2 December 2019 (EST)
To be more specific in my imaginings - an editor could upload a cover/interior art image and have the ISFDB software provide possible variants / merges. Anyway, not my main point. ../Doug H 10:10, 2 December 2019 (EST)
Yeah, and when I posted, the Note in acknowledging that this is a side comment stated only in the header of the message. On the main topic, I remember some concerns about copyright cited as a reason not to host too many of them but need to do some digging to find the threads. Annie 10:19, 2 December 2019 (EST)
Checking the database, I see that only one INTERIORART title (The Clewiston Test) currently has a "Webpages" link that takes you to an ISFDB-hosted image. And even that is only due to the fact that it's a back cover image.
Like Annie, I believe I recall discussions of copyright issues related to hosting scans of interior art. I don't remember all the arguments, but I think it was a gray area. I would be leery of uploading interior art scans until we have a better understanding of the issues involved. Ahasuerus 15:01, 2 December 2019 (EST)

In which I die at the end...

Personally speaking, I reserve a special place in hell for authors of those first-person stories (both short and novel length) in which nothing genre happens for the entire length, only to discover in the last paragraph that it has been narrated by a dead person. The story itself has been entirely non-genre from start to finish but this twist, for good or bad, changes everything. In or out? PeteYoung 07:21, 2 December 2019 (EST)

There are a number of variations on this theme. Sometimes it's reversed: the story appears to be SF, but in the end we discover that "it was all a dream". Alternatively, the narrator turns out to be a dog or another animal.
Typically, I include these borderline/"twist" stories and add a Note about any irregularities. Admittedly, doing it without spoilers can be a challenge. Ahasuerus 09:00, 2 December 2019 (EST)
I expect that an historical novel written in the first person would be non-genre, even if that perspective was a post-death recollection of events. So I don't think the mere fact it is narrated by a dead person makes it eligible. Regarding the "all a dream" situation, it is still fantasy writing regardless of the 'reality' of the fantasy. As for the animal narrators, if it's just to provide a narrative perspective, I'd say out. The degree of participation and analysis of the narrating animal would be the variable factor. ../Doug H 10:25, 2 December 2019 (EST)
Those and the Outlander-light and/or reverse romances (where the only speculative thing is that one of the heroes get dumped into a different time) and the "well, he is a fairy but lives as a human except that his house is never cold (or something)" novels always give me a headache. Technically they are genre. The one where the person narrating is actually dead and is narrating from an afterlife is even closer to the border than the romances... If the story is setting up the stage for a continuation where being dead (and/or a ghost) is important, I would add it. If not and it is a book I am adding... I will probably pretend the last line is not there (or that it was a diary or something) - so not eligible and skip it. If an editor adds it, it is technically eligible...
Pete, do you have an example? We can look to see where it is categorized in a library system maybe (as a guide of how people see the novel)? Annie 16:56, 2 December 2019 (EST)
I read a short story a couple of days ago in the anthology Singapore Noir, currently not indexed, which is what triggered my question: the narrator gets thrown off a skyscraper balcony to a certain death. A couple of others I can recall are Derek Raymond's novel A State of Denmark, which is certainly genre anyway, and Shan Sa's 2004 historical novel The Girl Who Played Go which we currently don't have in the db. It's the one I'm primarily considering. I'm inclined to agree with Doug because it's really a novel the db can do without, and I can't find commentary anywhere that remotely describes this novel as genre. To add a note that would read something like "Non-genre until the last chapter" doesn't really cut it for me unless there is a more fantastical twist that just 'the afterlife'. PeteYoung 07:12, 3 December 2019 (EST)
Then leave it out :) If another editor feels very strongly about it being genre or it starts showing up in our anthologies or become the start of a genre series or something along these lines, it will come back and get added later. Annie 11:11, 3 December 2019 (EST)

Moderator note on Publisher Edit

Can we add "Moderator Note" in the editpublisher page? And any other that does not have it but that is the only one I can think of now... Annie 15:30, 4 December 2019 (EST)

I support this idea. ···日本穣 · 投稿 · Talk to Nihonjoe 16:31, 4 December 2019 (EST)
I must have missed it back when I was adding the Moderator Note field to Edit pages. FR 1326 has been created. Thanks! Ahasuerus 16:47, 4 December 2019 (EST)
Done. Ahasuerus 18:14, 6 December 2019 (EST)

Clarkesworld - merging the two separate series

I want to merge the Clarkesworld (print issues) and Clarkesworld Magazine series (merging the Editors under them). The issues have the same contents, the only difference is the format and the grid now shows the uncommon formats so it will be clear what is what... Plus it won't look as if we are missing an issue altogether when we have it in only one of the formats (and now that we can clone magazines, people can clone for the other formats instead of doing all the work because they did not realize the issue is actually already in). Does anyone see a reason why not? Annie 17:00, 4 December 2019 (EST)

I'm not sure what drove it, but it's not the only one (see Stupefying Stories (print issues), Apex Magazine (print issues), & Lightspeed (print edition)). Whatever is decided should apply to all multi-format magazines. -- JLaTondre (talk) 18:12, 4 December 2019 (EST)
I agree with you, we need an overall policy but I have a Clarkesworld one in the pipe and I want to sort that one out :)
It was a "the grid will be too heavy" argument mostly -- plus the couple of magazines that do have different contents. It needs fixing - the current way makes half the grids weird and magazines change formats anyway - disconnecting them from each other is just weird and not all magazines are treated the same way so noone knows where we change from one policy to another. I tried to open the discussion for all of them (here in September and most people ignored it. So now I am trying from a different angle - show people that the merging of one of the major ones does not cause issues and weird displays and take it from there. Annie 18:21, 4 December 2019 (EST)
As I recall, one of the main reasons why we had different series for different magazine formats was that the software didn't allow you to clone magazine/fanzine issues. However, the software was changed in mid-2018 -- see FR 745 -- so it's not longer a concern. At another point we changed the software to display different formats on the Grid page intelligently, which addressed another issue with multi-format magazine series.
I agree with JLaTondre that it would be best to make a policy decision that would apply across the board first. Given the software changes listed above, I think we should be ready to revisit the issue on the Rules & Standards page. Ahasuerus 17:05, 5 December 2019 (EST)
I will post again then... :) Annie 17:26, 5 December 2019 (EST)
And R&S thread is posted. Please feel free to chime in there. Annie 17:30, 5 December 2019 (EST)

ISFDB On Browser

When I go into an individual entry than back to author page, isfdb on google chrome browser always goes back to top of page instead of bookmarking where I was. I do not like to have to scroll back down all the time. I don't know about the other browsers but I use chrome and someone in charge of this should look into the bookmarking problem Maybrick 19:51, 4 December 2019 (EST)

As a temporary workaround, instead of opening in the same tab, you can always open in a new tab instead. This way the first page never moves so when you close the second one (or just get back into the first one), it is where you left it. If you are using a mouse, it is a right click instead of left click.
I am not sure that the way our pages are built allows the browser to return where you were but Ahasuerus can confirm that for us when he is around. Annie 20:07, 4 December 2019 (EST)
The reason the browser shows the top of the page is that the ISFDB software always puts the cursor in the main "Search" box. This is something that was requested a long time ago in order to make it easier to get to the Search field. Some users have complained about this browser behavior for the reasons outlined by Maybrick above.
A compromise solution would be to make the Search box "sticky", which is to say that it would always be displayed at the top of the page no matter how far down you have scrolled -- see FR 1319 for technical details. It's a good idea, but older browsers do not support this functionality. We are still investigating how to do it right. Ahasuerus 12:11, 5 December 2019 (EST)
Sorry, I was the one who proposed that workaround, but I've been distracted by other personal projects in the meantime. Hopefully I'll get around to turning the proof-of-concept into a proper tested change submission sooner rather than later. ErsatzCulture 18:34, 8 December 2019 (EST)

The new tab is a good option for now. Thank you. Both firefox and explorer bowsers leave the main page bookmarked like they should. If you do could just do this with chrome browser that would be great. It really should not be configured differently. Maybrick 17:46, 7 December 2019 (EST)

It is not - not really. It is just how different browsers react to the focus command and mainly what they do when using the back button in them. Annie 17:54, 7 December 2019 (EST)

"Panther Granada" and "Panther / Granada" - Imprint / Publisher

There are 32 publications here at Panther Granada which I propose should be as "Panther / Granada". Some even refer in the Notes to Granada Publishing Ltd.

I have quite a few of these books and "Panther Granada" only appears on spines. The copyright pages on my copies usually start with Granada Publishing Limited (or Ltd) [over] Published in [date] by Panther Books Ltd.

Of the 32, only 5 were initially PV1 by active editors - 2011 2011 2011 2014 2016. Other active editors have added their subsequent PVs to many.

Please see also my recently added note to the record here Panther / Granada and the two sources given on the Wikipedia page.

What do you think? Thanks, Kev. BanjoKev 21:07, 4 December 2019 (EST)

Uhm... you cannot ignore active PVs just because they are not PV1. So if there is even 1 active PV, they need a ping for this - they decided not to change the record when they PVed so their opinion matters as much as that of PV1.
I am fine with merging these two records but let's not ignore half of the editors. :) Annie 21:22, 4 December 2019 (EST)
I have no objection... "Panther / Granada" seems the appropriate course as I don't think there was ever a publisher called "Panther Granada". Good catch, as far as I can see. PeteYoung 00:37, 5 December 2019 (EST)
I have no objection either.--Dirk P Broer 11:39, 5 December 2019 (EST)
Linguist pointed out that there are some old discussions about that with some of the inactive editors saying that there is a separation somewhere there. I will try to find them but does anyone remember anything? Annie 12:37, 5 December 2019 (EST)
There are two references on Mhhutchins' pages that seem to be relevant - are these helpful? [1] [2]. Kev BanjoKev 21:44, 8 December 2019 (EST)
The only things I found anywhere were from 2008 or thereabouts and part of the "as printed" vs normalized values conversations. So... I think we can safely merge -- anyone opposing? We can add a note into the inflicted pubs to that effect if we want? Annie 22:00, 8 December 2019 (EST)
Can this merge go ahead now? Kev. BanjoKev 09:08, 22 December 2019 (EST)
Thanks Willem. Kev. BanjoKev 20:43, 3 February 2020 (EST)

'Title Dates after Publication Dates' enhanced

The cleanup report 'Title Dates after Publication Dates' has been enhanced. The old version only flagged titles if the title year was after the year of the earliest publication associated with it. The new version also flags titles whose title month is after the month of the earliest publication associated with it. "00" months are ignored for now.

The data will become available by 1:30am server time. There are 5,000+ eligible titles, but the report only displays the first 1,000 for performance reasons. As we clean them up, new titles will be automatically added to the report every night. The report page is broken up into title type-specific sections: ANTHOLOGY, CHAPBOOK, COLLECTION, etc. Titles are alphabetized within each section. Ahasuerus 13:19, 6 December 2019 (EST)

The report is now below 500 titles. I was wondering if, after these are done the report will move on to the title/publication day, or if that's considered unimportant. I ask this, because some (at least one) moderator(s) now zero out the days when working on this report. Recent examples are here and here. We have a day of the first publication, and I can't see the merit of leaving known data out of the title record. --Willem 13:21, 12 January 2020 (EST)

New cleanup report - "Title Dates Before First Publication Date"

As per FR 1323, a new cleanup report, "Title Dates Before First Publication Date", has been created. At this time it is limited to the first 1,000 COVERART titles. There are roughly 4,500 affected COVERART titles, so it will likely take some time to clean everything up. Once COVERART titles have been taken care of, I will expand the report to include other title types.

Please note that the report doesn't let moderators "ignore" titles. I don't think "ignore" is needed when dealing with COVERART titles; I plan to add the functionality when we add more title types to the report. Ahasuerus 17:43, 6 December 2019 (EST)

Turns out we have a valid usecase where the first publication is later: here - because of how we do variants for pseudonyms. The parent title is not the first one used - so the date on the parent should have the date of the first variant. Which got flagged. Any chance we can filter these - it is valid only for the parent of a variant? Or will we need to simply ignore them (so we will need the option after all...)? Annie 01:58, 7 December 2019 (EST)
There is another issue here. The illustration was first used as interior art, but the first cover appearance is promoted to parent title. I can't find a rule for this. Shouldn't the first appearance be the parent, no matter how it was published? --Willem 04:15, 7 December 2019 (EST)
I would follow story rules of using the most predominate title as the parent. Of course that doesn't apply in your example (one occurrence for each), so I'd go with first appearance. -- JLaTondre (talk) 08:42, 7 December 2019 (EST)
Good suggestion. I'll see what other problems I encounter. Thanks, --Willem 14:38, 7 December 2019 (EST)
What about variants that are based on partial images? The larger images may be earlier or later, cover or non-cover and genre or non-genre. For example Battlefield Earth alone has 3 variations of the original art. ../Doug H 11:01, 7 December 2019 (EST)
I'm not seeing how that impacts the title or the date. Am I missing something? -- JLaTondre (talk) 12:34, 7 December 2019 (EST)
In terms of deciding which is the parent - the full image or the partials. In this case they all have the same type (COVERART) and name (Battlefield Earth) but are different 'images'. Would they be variants or lumped together? And if variants, which is the parent - the cover image in the most publications/printings or the earliest? Or the full illustration? I'm assuming each variant is dated for its earliest appearance. ../Doug H 17:26, 7 December 2019 (EST)
We treat cropping, extracts, color changes, etc. as still the same art. For ISFDB, variants are the same work under a different title; variants are not variations in the work itself (translations do use variants, but they are a special case and the GUI displays them as translations not variants). If we were to treat them as different art works, than they would not be varianted to each other & instead left as separate works. For such cases where they appear under different titles (and keeping with our current practice of treating them as the same artwork), I still think using the most common title or first appearance as the parent works. Or if there is a canonical title for the image, that can be used. However, we are starting drift pretty far from the topic of the clean-up report itself. If there is differing opinions on this, it should probably go to a R&S discussion. -- JLaTondre (talk) 08:35, 8 December 2019 (EST)
From a logic perspective, for parents, the clean-up report should check both the parent publication dates and variant titles dates and only report parents that are earlier than both. As variants are cleaned up, than it will find any parents that also need to be cleaned up (though hopefully whoever is doing the initial cleanup would have adjusted both anyway). -- JLaTondre (talk) 08:42, 7 December 2019 (EST)
Not what i am talking about. The problem are pseudonyms. Cover first done by pseudonym in 1952. We create a parent with the canonical and a 1952 date as well. In 1990, the parent title record is used in a book. Now we have a title which is with a date of 1952 but first publication in 1990. And we want it this way. We just need to treat parents differently in this report. Or have the ability to ignore them in these cases. Annie 12:10, 7 December 2019 (EST)
It is exactly what you are talking. For parents, if the report checks both the parent's publication dates and the variants' title dates and only outputs cases where the parent date is earlier than both, it will skip cases where first published under a pseudonym, first published as interior art, etc. -- JLaTondre (talk) 12:30, 7 December 2019 (EST)
On a second read, we are talking about the same thing indeed (not sure what I misread). But the report does not do that now - thus the post. :) Annie 12:34, 7 December 2019 (EST)
Correct, which is why I gave a suggestion on how the report could be tweaked to avoid those cases. :-) -- JLaTondre (talk) 12:56, 7 December 2019 (EST)
For artwork that first appeared outside the genre, we could have dates before any publication in the database. A common way of handling that has been to record the cover as per the publication and than variant to the original artwork's titles. Here is an example. I would recommend we keep this approach (it seems a good compromise between recording it as it appeared in the genre and reflecting the original appearance), but that would require an ignore for coverart. -- JLaTondre (talk) 09:15, 7 December 2019 (EST)
As we agreed on over in R&S earlier this year, right? :) Not sure why a recommendation is needed when this is exactly why we created the report - so we can clean up all those weird dates (both in variants and in first appearances). Annie 12:10, 7 December 2019 (EST)
Which is why I said it needs an ignore... -- JLaTondre (talk) 12:30, 7 December 2019 (EST)
Why? Do you think that a cover should be dated 1523 just because the original is? As opposed to creating a parent for the 1523 painting and varianting under it? We agreed on the variants solution. Annie 12:34, 7 December 2019 (EST)
Depends on how the report works. If it is treating each title record individually, then it wouldn't be an issue. If it is looking at all publications under a title (both the parent's & the variants'), then it would catch those as well. The former is sufficient for the current issues. Longer term, we probably should have the second as I've seen cases where parents without pub have bad dates (much smaller issue though). -- JLaTondre (talk) 12:56, 7 December 2019 (EST)
Parents with no publications attached directly are not on the report. :) Only ones that have. Annie 13:11, 7 December 2019 (EST)
Yeah, I just came back to say that it cannot be the latter or we wouldn't have the pseudonym issue. You beat me to it ;-) -- JLaTondre (talk) 13:14, 7 December 2019 (EST)
The opposite happened above where I misread - I was typing to that effect and you beat me to it. We both can use some coffee I think :) I think we are on the same page here. Annie 13:17, 7 December 2019 (EST)

(unindent) Thanks, I'll take a look. Ahasuerus 15:57, 7 December 2019 (EST)

I have experimented with the change proposed by JLaTondre. It's doable, but every approach that I have tried so far takes a very long time to complete. Normally it wouldn't be that big deal since we run this report once a day, but it locks all Title and Publication pages while it runs. For now, I have limited the report to Variant Titles while I am working on a more comprehensive solution. There are almost 3,000 affected COVERART VTs, so it will give the "cleaning crew" something to work on while I am experimenting on the development server.
Please note that the change took effect as soon as the patch was installed 10 minutes ago. For technical reasons, the report displays just 366 COVERART VTs at this time. The number will go back up to 1,000 when the report is re-run overnight. Ahasuerus 12:46, 8 December 2019 (EST)

Variants dated before their parents

Can we plan on one more dates mismatch based report -- variants dated before their parents. Two usecases that leave these are:

  • A title authored by a pseudonym is added via adding a book. We need to make a variant so that the title goes to the canonical page. An older version of the story under the pseudonym is added later so the merge/update takes care of the original story date but the parent's date is never adjusted.
  • A variant is connected to a pre-existing parent and the parent's date is not cleaned up.

This will get the mis-dated titles which we are not catching with the other reports. Thoughts? Annie 14:59, 7 December 2019 (EST)

There are two valid cases of this per the rules:
  • Novel first published as a serial. Parent is given date of first novel appearance.
  • Translation published before the native work. Parent is given date of first native work appearance.
Both cases should be able to be automatically excluded from the clean up report though. -- JLaTondre (talk) 15:33, 7 December 2019 (EST)
Yep. And we may have some corner cases as well. Excluding all the serials/novels combinations will catch the first case; the latter will need a human eye - as we may just be missing the first pub so we should not exclude automatically - moderator ignore will have to do upon verification. We probably will need to have the opposite report for the serials/novels anyway (if we do not change the rules - and even if we do) - they are not consistent in the DB either. :) Annie 15:40, 7 December 2019 (EST)
Sounds reasonable. Let me take a look and see what I can find. Ahasuerus 14:21, 9 December 2019 (EST)
A new cleanup report has been coded and deployed. The data will become available when the nightly job runs at 1am server time. I expect roughly 2,300 titles to be flagged. Moderators will be able to "ignore" titles. Ahasuerus 20:55, 9 December 2019 (EST)
Out of curiosity, does it exclude Serial/novels combos? Annie 21:20, 9 December 2019 (EST)
All SERIAL VTs are currently excluded. As per Help:Use of the SERIAL type#Date, the SERIAL date rule applies to all SERIAL VTs regardless of the title type of the parent title. Ahasuerus 21:24, 9 December 2019 (EST)
Thanks for the confirmation. :) Annie 21:30, 9 December 2019 (EST)
How do we want to handle this case which is showing up in the report? Parent has a date of "1904-10-01" and variant of "1904-10-00". Just ignore it? Flip the variant? I'd argue that 1904-10-01 is actually earlier than 1904-10-00 since the latter can be any day within the month. Seems like we should have a consistent implementation on order when dealing with "00" dates. Should we start a R&S discussion? -- JLaTondre (talk) 18:31, 10 December 2019 (EST)
I'd say that we need a discussion. I also consider 00 to be later than any other date in the month. On the other hand we have thousands of titles with 00-00 at the end in publications with a real date or month as pub date so if we go this way, a lot of them will need fixing... We may need somewhat of a blended approach - but we need a single approach... Annie 18:43, 10 December 2019 (EST)

Necroscope

I would like to cleanup the title names in this series - drop the series name and number from the titles (the ones from Vampire World will stay as they are of course). Take for example Necroscope II: Vamphyri! (link without variants). It even has a variant Vamphyri!. But if you look at the books under each of the variants, they are all mixed up. Then in "Necroscope V: Deadspawn", we have a variant "Necroscope: Deadspawn".

Any objections to cleaning this series as per current practice (aka - the series name is not in the title)? Annie 20:13, 11 December 2019 (EST)

Publisher Signed First Editions

Markwood has brought up a policy question about first editions where the publisher produces a small quantity of signed copies, but without other differences from the trade edition. The genesis of the concern arose with a DAW hardcover chapbook, where the signed copy apparently appeared on Amazon.com; there now seem to be copies for sale on bookfinder.com, but no longer on Amazon. Should these editions be listed as separate from the trade edition, or just have a note of their existence in the notes? Bob 15:22, 24 December 2019 (EST)

If the only difference is that they were signed in a bookstore for example, they are the same edition - they are not different from me tracking an author on a convention or the signed editions most publishers have on WorldCon for example.
If it is a bound signature or otherwise different (including a different cover and not just a sticker on the standard one for example being the only difference) or the publisher did otherwise differentiate between the two (not the sellers but the publisher), they are different and get their records.
Just my 2 cents. :)Annie 16:04, 24 December 2019 (EST)
Not signed in a store, but direct from the publisher. Maybe you haven't seen such before, but they do exist. Bob 17:31, 24 December 2019 (EST)
That's why I said above that if the Publisher considers them different, they should be treated as different IMO... Annie 18:30, 24 December 2019 (EST)
Publishers also have signed copies that are no different than bookstore signed editions (no change in binding, no change in printing, etc.). What is the difference between that and bookstore signed editions? I agree if a publisher releases it as a limited / signed edition where it is marked as such in the publication than it should be recorded as different. If however the publisher simply has the regular edition signed (which seems to be the case with this one), than it is not a different edition / printing. We should be recording based on the publication itself, not the marketing. Pub notes can be used for the marketing. -- JLaTondre (talk) 08:30, 25 December 2019 (EST)

Delete Data, change formulations, wrong data

I would like to ask all moderators and users to stop deleting or changing external data, such as e. g. in this publication. It is not clear who entered this data as a note and where it came from because the source is missing. I was also not informed about these changes in advance. This data (notes) does not come from me (PV), but gives the appearance. Unfortunately, it is an unfair custom, which is becoming more and more common to arbitrarily change third-party data according to his taste (Google translator).--Wolfram.winkler 10:06, 27 December 2019 (EST)

+1 with Wolfram, that's why I choose not to participate in such a project that let a few people enter what they want on PVed records (data or format) without being bound by any kind of rule. C1 11:29, 27 December 2019 (EST)
Well, as stated before at Wolfram's talk page: the purpose of this site is to share bibliographical data, not to hide it. Stonecreek 10:40, 27 December 2019 (EST)
Well, as the author of this brillant update (based on strictly nothing and just plain wrong confronted to the book and your own typographical usage), bibliographical data seems not really to be your forte.C1 13:17, 27 December 2019 (EST)
C1, you should quit with these attacks, and read this. You're on the brink of your first warning. --Willem 14:21, 27 December 2019 (EST)
C1, do you want to participate and help improve this project? Then the best way is to be constructive and cooperative. I know that participating in this project can be very frustrating, but attacking others the way you do is definitely helping nobody. So, as for the example submission you posted, why don't you simply state what is wrong with it instead of making us guess and blaming people? Since we don't have a change history for database records and therefore no previous version of the title I can only guess that you are referring to the missing space before the exclamation mark, because in French there has to be one, and that Christian has wrongly removed the space. Was that the problem with this submission? If so, why don't you just tell? Nobody is omniscient, everybody makes mistakes. We help, you lean. You help, we learn. If, on the other hand, your intent is to be as uncooperative as in your first answer you posted on your talk page it's no wonder that you get ignored after a while. Jens Hitspacebar 16:19, 27 December 2019 (EST)
It is common to add missing bibliographical data, especially vital one, such as information on edition, editors, source of printing. Since you tend to hide such data, you are invited to state what's wrong with the added data. Please prove it by scanning & uploading the copyright page. Thanks, Stonecreek 10:40, 27 December 2019 (EST)
You're right, adding more data to a publication as a primary verifer in the first place would be a lot better and make it unnecessary for others to add them later. But Wolfram nevertheless has a small point here regarding the publication's note: he had only stated the printing information there in his submission, and you, Christian, added the rest of the note's text afterwards. Right now the record looks like Wolfram verified all this information, which is not entirely true. If casual users who just stop by are not able to detect that some of the data of a record aren'ty PV'd, the PV system becomes a bit pointless. That's not only a problem with the publication in question here, but in general, e.g. if a primary verifier is not active anymore. Therefore, non-trivial changes to PV'd records should be made clear in the note: which data came from the primary verifier initially and what was added or changed afterwards by someone else who isn't a primary verifier, e.g. with a separate paragraph starting with "The following data are not primary verified and were taken from external data source x". See also the discussion "Notifying the PV - rule update needed?". Moreover I think that, compared to the current practice, all editors should generally put a lot more information about non-trivial changes to PV'd records into the submission note in order to be able see in hindsight what was changed in (or removed from) a record. Jens Hitspacebar 16:19, 27 December 2019 (EST)
Only that in Wolfram's case he has been asked numerous times to state what exactly is printed in a given publication and to correct erroneous or add missing data (see his talk page). He never has taken side to the needs of bibliographical information, which may be caused in deficits in his knowledge of the used terms and/or the English language. That's why it really would be helpful to upload the copyright page or state where it should differ from the one displayed with Amazon.
In this special case the one information stated in the notes was erroneous (speaking of a 'version') and unsourced. It is now sourced. Christian Stonecreek 23:50, 27 December 2019 (EST)
You're completely right about the current quality of his submissions, but that was not the point I was making. I'm not against corrections and additions like this. I wanted to point out that we have a general problem with the PV system if non-trivial data is added to an already primary verified record that doesn't come from a copy of the publication you have in hand, is therefore unverified data and if it isn't made clear somehow which data is primary-verified and which is not. That's a problem regardless of how bad the quality of the data in the verified record was before. Like I wrote in my previous post above, this scenario is sure going happen if a primary verifier is not active anymore and data is added to his or her primary-verified records. We must find a way to make sure that users can see what kind of unverified data were added after a primary verification, otherwise the PV system becomes meaningless. That's what I was referring to when I said that Wolfram has a small point here: his statement from above that "It is not clear who entered this data as a note and where it came from" is correct, no matter of the quality of the record before. I'll continue this on the Rules and Standard wiki page. Jens Hitspacebar 05:14, 28 December 2019 (EST)
Discussion started here: Clarify how to deal with unverified data added after primary verification Jens Hitspacebar 06:17, 28 December 2019 (EST)
A few words about user Stonecreek: "Version" in German means "Version", "Fassung", "Variante", "Ausgabe". Exactly what is meant to be expressed, so it is by no means wrong, quite the contrary. It means this edition is the 6th edition. You change the entry to: "Stated sixth printing". These are falsifications of the original input. So it is not corrections of incorrect entries, as you keep saying, but deliberate manipulations. Your further entries have no source information, are therefore useless or even wrong. I will correct them shortly. By the way as PV I don't need sources, the data are all from the book I own!
I ask you once again to refrain from making such changes. If you disagree with my wording, you have to live with it. It does not give you the right to change them arbitrarily. The bad thing is that you are a repeat offender who takes no account of the time-consuming work of other users and brutally and senselessly destroys their input.
Of my more than 100 entries, many were redesigned according to your taste under the guise of non-compliance with rules (which, however, were never named), that affects not only my entries but e. g. also from Rudam, who had the same negative experiences with you.
As a PV, I can decide which data I enter, which has nothing to do with hide. There is information that is completely unimportant, but everyone decides for themselves or is there a rule that requires all data to be entered? Certainly not!
@ C1, on the whole I share your opinion, but I also have to agree with Jens that you cannot see in the example why you criticize this update ...
First point : On the title page on my physical copy of the book and in the national (here french) typographical rules (that are to be followed here), there is always a "solid" space between the last word and the "!", so Stonecreek's "correction" results just in the insertion in the db of false (as per physical book) and improper (as per rules) data. Second point : The more appaling to me is the hubris and the total lack of respect that is exhibited by a moderator (who should know better) who, without any discussion, think that he has the right to change the title of a book that he does not have, that he will never see, in a language that is not his own and that is PVed by two persons. Such pretentiousness to "correct" data without having any knowledge of the subject and in contradiction with physical data is just idiotic and rude. C1 13:21, 31 December 2019 (EST)
@ C1: Quoting you: "On the title page on my physical copy of the book and in the national (here french) typographical rules (that are to be followed here), there is always a "solid" space between the last word and the "!""
Same question again above, still unanswered: Why didn't you simply post that information on Christian's talk page when the change happened? He was either not aware of this fact, or actually was but had forgotten about it temporarily. He would have answered something like "Thanks, I didn't know about this" and the title would have been changed back into the correct state. Problem solved and no more discussion necessary. Benefit for all involved: 100%. Yes, it would have been possible for him to do research before such a change, but as has been stated many times now: we are all volunteers and we all make mistakes or just miss something, therefore things like that can happen. It'd be great to see a fact-based answer free of attacking words to my question by you. Jens Hitspacebar 07:06, 2 January 2020 (EST)
@ Willem, please come back on the carpet, telling the truth or at least his opinion is not a crime, not everyone is a diplomat, and need not be.
There is still a lot to be said on this topic, but I don't feel like it at the moment. A discussion has started again, which will probably be fruitless again ...
I repeatedly ask all users and moderators not to misuse third-party data, in this sense I wish you a happy new year 2020 (Google translator).--Wolfram.winkler 09:42, 31 December 2019 (EST)
Hello all. I believe there are a couple of truths that can be distilled out of this discussion:
  • If you PV a publication, make sure that sufficient data is added into the notes. It is an 'obligation' of every editor to complete any missing or correct erroneous data. Merely PV-ing a publication without adding/completing/correcting data is insufficient.
  • Changing primary-verified 'core' bibliographic data must be done -very- cautiously, and it must always be clearly communicated to the PV-er(s), either through their talk page, or through a clear and unambiguous note in the Note to Moderators field to ensure it can always be traced back.
  • Adding third-party data to a PV'd record is acceptable. When added, this data must be sourced - see the discussion and feel free to contribute here: Clarify how to deal with unverified data added after primary verification
I think we can all agree on these rules, don't we? I believe much irritation could be avoided if both editors and moderators alike take these at heart. Also, it doesn't hurt to be reminded from time to time:-)
Also, don't forget that we are all human and that we all make mistakes - be it because it's an honest mistake, or because of a mis- or incomplete understanding of the rules and their intricacies (for example, a misinterpretation because a rule has been updated/changed/reversed is easily made - as evidenced by the example C1 gave above on the French language rules to apply). These mistakes and misunderstandings are easiest solved if we keep communicating with each other and continue to share knowledge and information - after all, we're not omnicient :)
@Wolfram, @C1, I would like to encourage you both to keep explaining clearly to us what you think we are doing wrong - it's the only way to reach an agreement amongst all contributors. Sometimes we may be slow in understanding what the issue is, and thus come to a consensus, and you'll likely have to repeat several times, but we'll eventually get there. That said, Happy New Year to all of you ! Cheers ! MagicUnk 14:09, 31 December 2019 (EST)
It's the whole WIKISLOPE (sic) that is wrong (for me at least). "Super" users that allow themselves to add erroneous data (Stonecreek see above or his/her dealings with Wolfram), to discard the rules that they are supposed to enforce (Dirk P Broer as in here where credit should be to the canonical) or to put their preferred format of notes everywhere (Linguist and his/her li-ul business) like my cat does. Such people are behaving like there are in conquered bibliographical land and seem to pass their time roaming the db unknown lands (for them) for things to change to their liking or to apply new mistakes to. Instead of this, they should go back (or stay with) to the real bibliographical work in the physical world, this would avoid to publish such stupidities as this brillant variant that will likely find its way all over the net that real research (you can even open the book itslef, it's magical!) should have ruled out (the french collection is an original one as the dates and the paratext show easily). This page also dispalys the results of the annoying habit of entering data without knowledge of the subject as the "Win (as La ménagerie de papier) 2016 Imaginaire Nouvelle étrangère " is for the short story and not the whole book.C1 04:20, 1 January 2020 (EST)
You are incorrect in one respect. Per the award's website, the award is for the "recueil" or collection rather than the story. I think you'll find that collections are frequently nominated in the nouvelle categories. --Ron ~ RtraceTalk 09:50, 1 January 2020 (EST)
ISFDB is a collaborative site. Like wikis you reference, that means people need to communicate & understand that there are community standards. Another "WIKISLOPE (sic)" is users who don't want to collaborate/communicate and only wish to complain which also contributes to poor quality data in the database. Now that you have explained your issues, I have fixed the Libérez l’homme ! title and unvarianted La ménagerie de papier (plus adding a note about it being an original French collection). Had you simply edited these yourself or dropped a note explaining your issues on this page, these could have been fixed along time ago. When you simply rant about problems with no explanation, there is no way for those of us unrelated to the issue to be able to help. Also, Wolfram & you seem to be under the misunderstanding that primary verifiers somehow "own" their primary verified records. This is not the case. If other people wish to add additional information, they are more than welcome to (as long as they indicate what data come from what secondary source). As for your comment on the 2016 Imaginaire, I can only go by the Google Translate, but the award's website lists "recueil" (which Google translates as collection) next to the title. You will need to provide more info for us to help you on that one. -- JLaTondre (talk) 09:45, 1 January 2020 (EST)

(unindent) Without trying to comment on any of the specific examples, and leaving aside the discussion about how to document non-PVed information, two things seem pretty clear to me:

  1. More than one active editor/contributor is finding their PVed information altered without their knowledge, in ways they consider significant and in ways they do not necessarily agree with. Regardless of what anyone else thinks, and regardless of any bottom-line correctness or innocuousness of the changes, that is the perception.
  2. Moderators are making editorial changes that are more than just purely cosmetic and are not always following the notification etiquette that is de facto ISFDB policy: ask PV(s) before making a "destructive" change (deleting or altering existing data), notify PV(s) of any data added, with such notifications adjusted according to any preferences given on a PV's talk page. Granted, there are shades of gray in the nature of some changes.

Rather than being defensive or trying to justify our actions, we moderators need to accept #1 as a problem our role calls us to try to mitigate, and we must be very careful about #2 (not only for PVed records, but also when "correcting" submissions). To me, that means communicate more and look for ways to accommodate alternate viewpoints when insisting on the moderator-mandated approach. Remember that the spirit of the change notification process is to do our best to ensure that the changed record reflects the actual publication; ideally that means the PV will in fact verify the changes and is willing to confirm all information in the record not explicitly attributed to some other source. We may not achieve that ideal WITH notifications, but we cannot achieve that ideal without them. --MartyD 11:23, 1 January 2020 (EST)

First of all: A happy new year to you all! Principally, In the case of the complaining editor, he has been asked numerous times to correct erroneous data (for example supplying the correct page count, add missing data, and using established bibliographical terms). Especially, he has recently been asked to supply information on the number of printing here. He did anything to not supply this information, whgich would have been quite easy for him, as I could verify when I hunted down a copy of the publication. It strongly seems he wants to impose his own system of notification & indexing that deviates in several ways from the ISFDB standard. He hasn't proved one single case of adding falsified (or changing to it) data - as per ISFBD standard.
It's a rare case but from time to time we seem to meet editors who don't want to follow the rules (or can't because they didn't study them). Christian Stonecreek 13:30, 1 January 2020 (EST)
A very good and peaceful 2020 to all. I think Marty explained our etiquette far better than I could. I hope all moderators (and hopefully editors) will act like accordingly. Unfortunately we are dealing with one editor (@ Wolfram) who had some bad experiences and now thinks all moderators are evil, and one editor (@ C1) who obviously has no intentions to participate in this project at all (still zero edits to his name) and only wants to complain and whine about how bad we all are. The notification on his talk page is an open invitation to all to do anything to his verifications without notification, so he should not be surprised.
@ Wolfram: as has been explained before, we are all volunteers (and I have no idea why I should come back on the carpet, or what you mean by that, even Google translate is baffeled)
@ C1: if you don't start coöperating, I will ignore you and your verifications from now on, and more personal attacks will eventually get you banned from this site. --Willem 15:51, 1 January 2020 (EST)
@ Stonecreek, it goes to far that everyone has to prove PV that his entries are correct. Your inputs are here without source
and therefore worthless, but worse is that my note from you has been changed arbitrarily and only this is the theme of this thread. All related Problems only arise from your misconduct. Look at my first
inputs, you will see that I have detailed listed the data from the books, well structured and therefore easy to read, usually hardly any corrections were necessary.
Then you started to change my formulations and destroyed them thereby the work of hours, simply because you don't like my presentation of the notes or because I use colons and rhombus or is it envy?
Since these illegal interventions, I've decided to enter only the most necessary details. I also want to point out that there are no rules regarding the presentation of the notes, either if you maintain this permanently and refer to ISFDB rules (of course without source / links).
@ Jens, the quality of my entries is actually good, I have just described the reasons for the missing entries. Otherwise, all data are from the books.
@ MagicUnk, please read the thread from the beginning ...
@ JLaTondre, it is not the case that I "own" data. I object to my data being changed/falsified or even deleted and that includes my notes. In the current case "my" data (notes) have been changed and further data has been added without citing the source. According to your statement, this is wrong, so what is this demagogy about?
There are two separate issues here. If Stonecreek entered data based on a secondary source and did not source it, that is incorrect and should be fixed. I will follow-up on that below. However, if an editor wants to add information from a secondary source and properly sources it, they are allowed to. Simply because you verified the pub, you are not able to say you don't want that data included (as how you started this thread & seem to keep repeating). You are not being ignored. The community has already formally changed the rules that secondary sources need to be documented and a software change has been made to require an explanation when changing a primary verified pub. You raised valid points & there was agreement there. But that does not mean it's correct to demand no one edit pubs you verified. -- JLaTondre (talk) 17:10, 14 January 2020 (EST)
@ MartyD, I am speechless...
@ Stonecreek (again), why I am not entering any more data, I have explained sufficiently. I am convinced that you all of us want to put your stamp on it by using your personal "style"
ruthlessly want to dictate to other users, I'm not the only one to whom this happens. There is enough evidence of tampering, look at my former PVs. Was stimmt nicht mit Ihnen?
@ Willem, I'm also just a volunteer, with little time, so much the worse is it when a moderator Stonecreek sabotages this collaboration by changing data (notes) according to his taste, everything under the
pretext to act in accordance with the rules. but he is the one who disregards clear rules. "Come back on the carpet" means to act less aggressively, to threaten an user because he is telling the truth, is a bit exaggerated.
@ C1, I'm glad there is someone who says the truth, even if it makes him unpopular. I don't agree with everything you told, but for the most part, it is o.k.
At the end I quote a politician: Willest du den Charakter eines Menschen erkennen, so gib ihm Macht. If you want to recognize a person's character, give him power (Abraham Lincoln). Guess who.
I hope, everyone understand this perfect Google translation, I do not. --Wolfram.winkler 02:54, 8 January 2020 (EST)
And again Stonecreek has deleted my PV data here and entered data without source. It is terrifying that a moderator can do what he wants here, against all the rules (Google). --Wolfram.winkler 02:37, 14 January 2020 (EST)
Wolfram, there wasn't deleted anything, there only has been information added! It was you who tried to delete information. If there's something stated erroneously, please tell us which thing it is.
As you have shown numerous times that you either 1) didn't read the rules, or 2) have read them but didn't understand them, or 3) have read & understood them, but are not willing to follow them - for example on entering the correct page count, entering all relevant contents, using correct capitalization rules, and using the bibliographical terminology ISFDB shares with the bibliographic world.
You have shown that you are not willing to use the English language here on ISFDB, or help others when asked for information (see this argument - and it wasn't me that asked for information, it was your friendly neighborhood Annie). This is just not the spirit we encourage here. Accusations that are not documented by at least one example are counterproductive, and are likely to avail nothing. If you will be able to change this attitude there's nothing that'd speak against you becoming a respected editor. Christian Stonecreek 03:14, 14 January 2020 (EST)
Stonecreek, you have not verified the pub, but you have added data to it. Where did that data come from? If it came from a secondary source, then the source needs to be stated. If it came from the pub, then you should have verified it. Please clarify what is going on. -- JLaTondre (talk) 17:10, 14 January 2020 (EST)
The data is from Amazon's look inside, available to anybody. Wolfram has been asked (like in the argument with Annie), to state which information is actually printed in his book, but keeps evading this point. Christian Stonecreek 02:25, 15 January 2020 (EST)
@Wolfram: I have some further questions for you as apart from the obvious argument that changes to PV'd records need to be carefully documented (BTW, these are now mandatory - see here)., I still don't fully understand other aspects of your concerns. So,
1) Can you tell us if the information that has been added/updated by Stonecreek is incorrect or not? In other words, does it reflect what is in the book or not?
2) If the information added/updated by Stonecreek is incorrect, please tell us what exactly is wrong with the current information for Der Totengräberson (copied below - see also here)
New, revised edition.
The copyright is assigned for the year 2017 to the author.
Text editor: Catherine Beck.
Stated sixth printing.
Thank you. MagicUnk 10:03, 15 January 2020 (EST)
Only the data: "Version: 6th printing" and "Lektorat: Catherine Beck" come from my book. The source should be specified for his further entries. The Amazon view of the book refers to the 1st printing.
Furthermore, no formulations may be changed, this is also a falsification of data, which is always done by Stonecreek. He can add data to the notes of my PV publication, but without changing any of my data!--Wolfram.winkler 03:27, 23 January 2020 (EST)
Again Stonecreek changes my PV data here and here with his own not verified data and without source. The bad thing is, that he even changes wording, even if the data is correct. Who stops Stonecreek?
I wish a statement from an administrator whether this behavior is correct or not! If this behavior is tolerated, I can save myself more time wasting on working here. My advice: clear his moderator flag. Stonecreek behaves like a berserk, destroying and changing a lot of data from PVed pubs (asks Rudam, C1, Willem, Magicunk, Annie). --Wolfram.winkler 02:52, 31 January 2020 (EST)

Adding a repeatable "Web Pages" field to Publication records

FR 957, Add a repeatable "Web Pages" field to Publication records, is about to be implemented. The new functionality is similar to the existing "Web Pages" functionality available for other ISFDB records. Please note that New Publication edit forms will now have two "Web pages" multi-fields: one for the new Title record and one for the new Publication record.

While the software patch is being installed -- which shouldn't take more than a minute or two -- many ISFDB Web pages will be frozen. Once the update is in place, I will adjust Help to reflect the new functionality. If you encounter any problems, please post your findings here. Ahasuerus 19:05, 27 December 2019 (EST)

The patch has been installed. Editors will need to do a full page reload (Control-F5 under most browsers) for publication-related edit forms (NewPub, AddPub, ClonePub) to work correctly. Ahasuerus 19:25, 27 December 2019 (EST)
We have a bit over 48K publications with links inside of them (searching for "http"). Some of them will remain links (when it is there for covers comparison or credit sourcing purposes, pages that list multiple books (adding a page with all editions of a book to all the publications does not make sense IMO even when it is the source - these need to stay in the notes - I am open to being convinced into the opposite though if someone thinks it makes sense) and so on) but some will need to be moved to the new fields (not-external ID eligible sources and so on). Cleanup report with the ability to ignore? Annie 19:16, 27 December 2019 (EST)
Cleanup reports are the next step. One of the existing ones, Publications with Wiki pages, checks if Wiki-based publication-specific pages are linked in the Notes field. It will need to be adjusted now that publication records have a "Web Page" multi-field. Once that's been done, we can disable the "Bibliographic Comments" link. In addition, many Wiki-based pages for existing publications (like this one and this one) need to be folded into regular Note fields. When this report and its 236 pubs are out of the way, we can re-assess where we are and create additional cleanup reports. Ahasuerus 20:06, 27 December 2019 (EST)
Yeah, there is that. And back into all the old records we go again, fishing out more and more links :) Annie 21:22, 27 December 2019 (EST)
Hi, I'm not clear on the usage: should I move the links I've been embedding in the notes of my submissions (like here) to the new multi-field, but leave the notes' text unchanged otherwise? (Would definately make it easier:)) Thanks! MagicUnk 02:27, 28 December 2019 (EST)
You know how you add the ID for the PPN only in the External IDs and put in the notes just PPN? Same here. bol.com links go up in the new fields, the text says bol.com (or whatever user friendly name this has). Annie 04:45, 28 December 2019 (EST)
Great! As I suspected, then :-) Thanks for the confirmation. Will help a lot. MagicUnk 05:42, 28 December 2019 (EST)
Two recommendations on the display:
  • Can it moved down after the notes and before external ids? The links are not from the publication itself so seem better grouped with the external ids as secondary source data.
  • The current display is missing a bullet before the Webpages label (see example)
Thanks. -- JLaTondre (talk) 10:19, 28 December 2019 (EST)
The missing bullet has been added -- thanks for reporting the bug!
Re: moving the new field below the Note field, keep in mind that all other bibliographic pages -- authors, titles, etc -- display this multi-field above the Note field. Ahasuerus 14:21, 28 December 2019 (EST)
In this case, I think consistency doesn't help. More clearer delineation between primary verified data and non-primary verified data what be better. Especially in light of this conversation. -- JLaTondre (talk) 17:23, 28 December 2019 (EST)

Web Page Search bug

I am not sure but methinks I have run into a bug with regard to web page search:

I just went to Advanced Search -> Web Page Search and entered "ndl.go.jp" in the box leaving the operator drop down selector at its default of "contains". Notice under "Authors" it says:

1 波津尚子 http://id.ndl.go.jp/digimeta/4411087/eng

But if you look at the referenced author its single webpage field says: https://id.ndl.go.jp/auth/ndlna/01185236

Also notice there are no publications listed even though I know there should be many. Here is a publications search looking for web pages with the same contains value:

This includes the pub record S-Fマガジン 1978年07月号, #236 which has the webpage field value listed as being part of the erroneous author listed in the webpage search results above. I checked the HTML source and the issue is not there (not bad markup that just renders strange in the browser).

In looking at the code:

It looks like it was not updated for changes from the above FR (publications are not even mentioned). It is definitely the Python. Should we file a bug or reopen the existing one?

I am guessing you will want something like:

WEBPAGE_PUB    = 9

And for the future you can avoid at least the brokenness by skipping line biblio/webpages_search_results.py:100 when none of the fields above it is found (and perhaps you want to flag the known bug then). Meaning if that code finds a webpage record that it does not know about it should skip it and report it; not add the URL to the last understood record.

—Uzume 18:07, 18 January 2020 (EST)

This definitely looks like a bug. I'll take a closer look. Thanks for reporting the issue! Ahasuerus 18:39, 18 January 2020 (EST)
Good points. I believe it should be fixed now. Ahasuerus 18:13, 19 January 2020 (EST)
Yes, it looks like Bug 746 was fixed in r500. Thank you. —Uzume 06:27, 20 January 2020 (EST)

Nominating user MagicUnk for moderator

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

MagicUnk (talk • contribs) has been active for nearly two years now, and has shown remarkable progress in mastering the intricacies of the database. His user page shows good communicating skills, and the ability to at least self-moderate would also help him work faster, or with less effort. As of now he is close to 15.000 edits. He is willing and I think meets the Moderator Requirements.

Support

  1. Support, as nominator. --Willem 04:54, 28 December 2019 (EST)
  2. Support. Good idea! I haven't had any issues with any of his submissions in a very long time. --MartyD 07:09, 28 December 2019 (EST)
  3. Support -- JLaTondre (talk) 08:51, 28 December 2019 (EST)
  4. Support the "self-moderation" proposal. I think it would be a good intermediate step for now. Ahasuerus 14:25, 28 December 2019 (EST)
  5. Support - with a gentle recommendation to start with (mostly only) self-moderating and slowly ease into the rest -- as I said elsewhere, MagicUnk is extremely detail oriented and good at what he usually works on and his submissions had been clean for quite awhile - typos and so on notwithstanding. :) Annie 18:05, 28 December 2019 (EST)
  6. Support - I don't see much hindrance for gradually also moderating first some and then more submissions by other people. One has to learn all the time (as you can see by my example), and I think he now has knowledge of many issues and problems that can arise. Christian Stonecreek 01:55, 29 December 2019 (EST)
  7. Support - Strong support. I see no need for just self-moderating, he's good to go imho. There's no better way to learn than by doing. Bob 18:27, 1 January 2020 (EST)

Oppose

Neutral/Comments

Outcome

The nomination is successful. The moderator flag has been set on User:MagicUnk's account. Congratulations! Ahasuerus 15:51, 3 January 2020 (EST)

SERIALs added to "Title Dates Before First Publication Date"

The cleanup report "Title Dates Before First Publication Date" has been updated. Now that all COVERART titles have been corrected, the compilation logic has been changed to include SERIAL titles. The data will become available at 1:30am server time. I expect that the report will flag 73 problematic SERIAL records.

I couldn't think of any scenarios where a SERIAL title would legitimately have a date prior to its first publication date, so I didn't add the "Ignore" functionality to the Web page. My current plan is to keep adding title types until we come across titles which need to be "Ignored". Once that happens, we'll re-evaluate. Ahasuerus 13:55, 28 December 2019 (EST)

P.S. For VTs, the current breakdown of problematic titles by title type is as follows: 

   +--------------+--------------------+
   | title_ttype  | count(t1.title_id) |
   +--------------+--------------------+
   | ANTHOLOGY    |                 91 |
   | COLLECTION   |                248 |
   | INTERIORART  |              10485 |
   | EDITOR       |                  1 |
   | ESSAY        |               1757 |
   | INTERVIEW    |                 81 |
   | NOVEL        |               2190 |
   | NONFICTION   |                 73 |
   | OMNIBUS      |                 81 |
   | POEM         |                913 |
   | REVIEW       |                125 |
   | SERIAL       |                 73 |
   | SHORTFICTION |              10302 |
   | CHAPBOOK     |                 60 |
   +--------------+--------------------+

Ahasuerus 14:10, 28 December 2019 (EST)

Thanks, I'll take a look tomorrow. I can't think of a reason any variant should have a date before it's first publication. I.m.o. the problems will come when we move on to parent titles, so the first 25.000 should be easy and won't need to be ignored. --Willem 15:19, 28 December 2019 (EST)
I suspect that we may end up with two separate cleanup reports. The first one will handle variants and won't let moderators "ignore" records. The second one will handle non-variants and will support the "ignore" functionality. We'll see how things develop. Ahasuerus 15:52, 28 December 2019 (EST)
You are both assuming that the ISFDB has the first publication in the database. That is not always the case. It is probably true for serials, but it wouldn't surprise me if there is an odd case here and there. For variants, it is definitely not true. We have plenty of cases where a variant is known to have been published in a prior publication than we have in the database. In such cases, there should be a "first published in..." note. The proper way to "fix" that would be to add the publication, but with some older ones, that can be hard as there can be little data available to add. -- JLaTondre (talk) 17:18, 28 December 2019 (EST)
That may be a good way to start tracking down those missing first editions. We need them if we want to claim we are the bibliography site of the genre, don't we? :) And adding a stub publication with very little detail is not unheard of. Annie 18:02, 28 December 2019 (EST)
Yes, but experience has shown that the desire to fix clean-up reports has sometimes resulted in the baby being tossed out with the bath water (Reviews not Linked to Titles is a prime example where many valid reviews of genre books were converted into essays instead of properly fixed by adding the genre publication). The clean up reports are a good thing, but unfortunately they are not always used correctly. -- JLaTondre (talk) 20:12, 28 December 2019 (EST)
So we need to pay attention to how they are cleaned and not just fix blindly - which is how all these reports should be used anyway. If we have an editor who fixes just for the sake of fixing, we can work with them on that. I understand why you are concerned but these records need fixing - and without a report we cannot find them. A bit of a catch-22, isn't it? :) Annie 20:38, 28 December 2019 (EST)
Checking the data on the development server, I see that in quite a few cases first edition information is recorded in the Notes field. For the most part, it should be fairly easy to create skeleton publication records. Some titles which first appeared in ineligible pubs, e.g. non-SF ESSAYs originally published in non-SF pubs and later reprinted in SF pubs, may be problematic, but we'll cross that bridge when we get to it. Ahasuerus 20:12, 28 December 2019 (EST)
Yeah, we will have exceptions. Thus the ignore. But that does not mean we cannot work on the ones we can work on. Annie 20:38, 28 December 2019 (EST)
Talking about variants which are pre-dating their first publications, here is another example here. The original publication under the same title, author and text is not added (a single story in a non-genre collection); at the same time the date should be coming from there. Actually... I think that I will just add these collections tomorrow and mark them non-genre and add only "our" stories - they are eligible that way. Annie 02:59, 29 December 2019 (EST)

Stone Arch Books's DC chapter books

Stone Arch Books have quite a big series of DC comics based chapter books. At the moment, we seem to have the few that we actually do have all over the place -- some as a pub series and another one; some as a regular series and some not connected at all - this one is in the Catwoman series despite it being from the Batman line of chapter books.

I think that these will make sense as a separate title level series -- split into the subseries per hero where the numbers call for it (Green Lantern, Batman, The Dark Knight and The Batman and Robin Adventures are the early candidates) as opposed to being filed all over the place based on whatever hero they may contain and with a set of different pub series. These are juveniles only -- specially created for young readers so putting the Catwoman ones with the non-juvenile Catwoman titles does not make sense to me - they are for different demographics (and we can use a tag to find all Catwoman titles if needed). Thoughts before I add the missing ones and organize all of these? Annie 19:44, 28 December 2019 (EST)

In the worst case scenario, we need these into pub series -- although that will mean mixing all the separate lines inside of the DC Super Hero line... so finding anything becomes harder. I know we need a lot bigger discussion for the overall DC universe series but these are an easy subset that needs some internal logic. Annie 22:54, 28 December 2019 (EST)

Anthology : Collection grey area?

The Lovecraft volume in Gothic Fantasy (ISFDB anthology series and ISFDB publication series) contains among 35 collected/anthologized works 31 by Lovecraft and 4 by other writers. Hc format 686110 and ebook format 738691 are both in the database, as the unique publications of anthology by Laura Bulbeck (series editor) and collection by Lovecraft respectively. Is this a legitimate grey area? Should we choose ANTHOLOGY or COLLECTION for this one? --20:53, 30 December 2019 (EST)

It is an anthology - the one that was a collection had no contents and apparently I did not see the non-Lovecraft stories there. I've fixed the one that was added as an anthology. Thanks for finding it! Annie 21:12, 30 December 2019 (EST)
The Mary Shelley volume, now in the ISFDB publication series only, and as a COLLECTION, contains among 20 coll/anth works 12 by Shelley and 8 by other writers (publication record 688714, with contents only from part one, The Birth of Frankenstein). Hc format is a unique publication here, but the change to ANTHOLOGY by Laura Bulbeck, in ISFDB anthology series Gothic Fantasy, requires two updates that cannot be submitted at once --if i understand correctly. I have submitted the TitleUpdate that is appropriate as a first step. PubUpdate needed later, iiuc: author Laura Bulbeck; type ANTHOLOGY.
The other so-called curated collections now in the ISFDB publication series are genuine collections: no grey area; collected works by Poe, Stoker, and Wells only. Momentarily I add cross-references with explanations to the two Gothic Fantasy series records. --Pwendt|talk 14:35, 31 December 2019 (EST)
Approved and fixed the pub as well. When there is only one publication as was the case here, one update would have been possible - you can change the type on both the title and the publication at the same time - you need to do them separately only when you have 2 or more publications already attached to the title. Annie 16:37, 31 December 2019 (EST)

Publisher Directory is incomplete

The Publisher Directory as indexed by the first two letters may be incomplete. The entry for Übergrenzen seems to be unreachable from this index. ../Doug H 15:01, 31 December 2019 (EST)

It is a known issue with both the author and the publisher directories - publishers with a non-listed character in the first 2 letters of their name need to have a transliteration. I’ve added both ways someone can be looking for that one so it will show up either way now. That is why authors have directory names with no special characters - here it is the transliteration that gets them on the list. :). Annie 15:49, 31 December 2019 (EST)
Is this on a cleanup report or do I need to add the transliteration for publishers I add? (I have Lögberg in the queue) ../Doug H 17:46, 31 December 2019 (EST)
The report on Publishers catches the non-Latin1 ones but not these. I suspect we need to expand it the same way we expanded the Directory name for authors ones. Annie 18:02, 31 December 2019 (EST)
PS: And even if there is a report, it is a good idea to add it on the records that you create anyway :) Annie 18:07, 31 December 2019 (EST)

(unindent) An interesting discovery. First, let's make sure that we are all on the same page. The Author Directory page is built using the first two letters of the "Directory Entry" field of author records. The Publisher Directory page is built using the first two letters of the "Publisher Name" field of publisher records.

There are cleanup reports for these two fields, but they look for somewhat different things. The cleanup report for the Directory Entry field looks for any letters outside of the A-Z range. It catches characters like "Ü" and reports them as errors. On the other hand, the cleanup report for the Publisher Name field looks for values that are not in the "Latin-1" character set, which includes most letters used by West European languages, e.g. "Ü", "Û", "Ú" and "Ù". It's only when a publisher name includes a character outside of the Latin-1 set, e.g. "Ÿ" or "Š", and there is no transliterated value for the name that the cleanup report flags the record as an error.

In most cases characters like "Ü" do not need a transliteration. It's only when one of the first two characters -- which are used by the Publisher Directory page -- is non-English but within the Latin-1 character set that it creates a problem. Checking the database, I see that we have roughly 140 publishers with this problem.

I'll have to think about it and see if I can come up with a solution. It may be possible to change the way the Publisher Directory page is built to handle these non-English characters as if they were their English counterparts. Thanks for reporting the problem! Ahasuerus 19:22, 31 December 2019 (EST)

The following python code will ASCII'ize those characters:
import unicodedata
normalized = unicodedata.normalize('NFKD', title).encode('ascii', 'ignore').decode('ascii', 'strict')
where title is the data to be normalized
You could use that to create an ASCII'ized key value for the directory lookup. -- JLaTondre (talk) 10:01, 1 January 2020 (EST)
Thanks! It may also be possible to use MySQL's CONVERT(publisher_name USING ASCII) to ASCII'size the publisher name during query execution. I'll have to play with it to see what works best. Ahasuerus 10:08, 1 January 2020 (EST)
OK, I think I managed to zap the bug -- see this page. Ahasuerus 18:17, 4 January 2020 (EST)
I removed the transliteration that I added earlier - as it was also putting it there. But even without it, it is there now so we look good I think. Annie 18:38, 4 January 2020 (EST)
Excellent! Ahasuerus 20:31, 4 January 2020 (EST)

Do we know if we have this same kind of problem with series names and the magazine directory (I don't imagine we have many like this but it seems a potential pitfall)? —Uzume 13:10, 6 January 2020 (EST)

The Magazine one does: for example Yöjuttu is missing in Magazines that start with Yo. Annie 13:14, 6 January 2020 (EST)
Unfortunately, the Publisher Directory fix resulted in the data retrieval process taking much longer. It's not too bad because we don't have that many publishers, but my testing suggests that using the same process for authors or magazines would result in significant performance degradation. I could do more digging, but it doesn't look promising at the moment. Ahasuerus 14:44, 6 January 2020 (EST)
Authors are not a problem because our Directory names are clear from any accents and so on (right?)... Annie 14:49, 6 January 2020 (EST)
Right. Sorry, I have corrected my response above. Ahasuerus 15:10, 6 January 2020 (EST)
As a workaround for the magazines: Can you get a list of magazines which have this problem in their first two characters so we can add transliterations? That way at least we can get them on the grid. I knew about this one because I had worked on it before so I went to check it specifically but there are probably at least a few more. Annie 14:49, 6 January 2020 (EST)
Let me poke around a bit and see what I can do... Ahasuerus 15:14, 6 January 2020 (EST)
OK, the magazine directory has been adjusted to display magazines like Yöjuttu correctly. The change caused minimal performance degradation, but it had already been quite slow. I'll see what I can do to improve it. Ahasuerus 16:41, 6 January 2020 (EST)
I am assuming we are relying on transliteration fields for directory entries from entirely non-latin records except authors (where we have a directory field) and the only issues are non-ASCII latin-1 fields without ASCII transliterations. —Uzume 17:07, 6 January 2020 (EST)
Exactly! Ahasuerus 17:19, 6 January 2020 (EST)
Retrieved from "https://isfdb.org/wiki/index.php?title=ISFDB:Community_Portal/Archive/Archive47&oldid=644243"