ISFDB:Community Portal

From ISFDB

Jump to: navigation, search


ISFDB Noticeboards
Before posting to this page, consider whether one of the other noticeboards might suit your needs better.
Help desk
Questions about doing a specific task, or how to correct information when the solution is not immediately obvious.
• New post • Archives
Verification requests
Help with bibliographic, image credit, and other questions which require a physical check of the work in question.
• New post • Archives
Rules and standards
Discussions about the rules and standards, as well as questions about interpretation and application of those rules.
• New post • Rules changelog • Archives
Community Portal
General discussion about anything not covered by the more specialized noticeboards to the left.
• New post • Archives
Moderator noticeboard
Get the attention of moderators regarding submission questions.
 
• New post • Archives • Cancel submission
Roadmap: For the original discussion of Roadmap 2017 see this archived section. For the current implementation status, see What's New#Roadmap 2017.



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




Contents

Happy New Year, all!

And all best wishes for 2018... --Vasha 21:36, 31 December 2017 (EST)

Happy New Year! Ahasuerus 22:43, 31 December 2017 (EST)
Bonne année ! Linguist 04:28, 1 January 2018 (EST).
Thanks! And a happy new year also to you all! Stonecreek 10:10, 1 January 2018 (EST)
Happy New Year, everyone! Annie 16:09, 1 January 2018 (EST)
A few days late, but 明けましておめでとうございます。 ···日本穣 · 投稿 · Talk to Nihonjoe 20:21, 4 January 2018 (EST)

"The Ghost Club" pseudonyms -- how to handle?

A confusing book, would like to consult. William Meikle published The Ghost Club: Newly Found Tales of Victorian Terror, in which he writes "new" stories by famous authors. Looking inside the book, each story has at the top of it Title over Fake-Author (e.g. To the Moon and Beyond [over] Jules Verne). I thought that this would be entered into the database with Jules Verne as a "pseudonym" of William Meikle ("To the Moon and Beyond" by William Meikle [as by Jules Verne]). But Christian changed my submission to instead have the content records like so: "Jules Verne: To the Moon and Beyond" by William Meikle. This form of the title doesn't appear anywhere in the book. What do all you folks think? --Vasha 16:46, 1 January 2018 (EST)

While we credit per the pub, based on what you describe, these aren't real credits. Instead they are part of the framing of the story. I would treat them as subtitles (so 'Title: Fake Author Name') and add a note explaining the format to the pub notes. That seems to match the pub & our standards the best. -- JLaTondre (talk) 17:18, 1 January 2018 (EST)
(after resolving an edit conflict) If Jules Verne had nothing to do with writing the story, then making the author a pseudonym of him does not make much sense to me. Otherwise anyone that ever wrote a pastiche will need to be pseudonymed as well.
So if I understand what the book contains, I am with Christian on it - the ":" is similar to how we record subtitles - the name we use then is nowhere in the book either in a lot of cases. Add a note in the collection can explain how the names are actually written. Annie 17:21, 1 January 2018 (EST)
OK, so noted. --Vasha 17:33, 1 January 2018 (EST)
Yeah, the other possibility would have been to establish one-time pseudonyms like (for example) Jules Verne (I), Jules Verne (fraud), Jules Verne (William Meikle), or others, and that would have been not really been nicer, or would it? Christian Stonecreek 10:36, 3 January 2018 (EST)

Fabian

I just opened a can of worms after discovering that http://www.stephenfabian.com/ is signed with Stephen E. Fabian Sr.--Dirk P Broer 08:30, 3 January 2018 (EST)

Wikipedia also has the 1930 illustrator as being Sr.
We did have Jr. as the main Fabian and Sr. as an occasional contributor, but it is the other way around. In collaborations the main Fabian names himself Sr. and his son then takes the main name his father uses...--Dirk P Broer 06:27, 4 January 2018 (EST)
Oh, great! It didn't occur to me that there are two artists (father and son) involved. Christian Stonecreek 06:42, 4 January 2018 (EST)
But how do we correct this? Stephen Fabian as presented is Stephen E. Fabian Jr., and Stephen E. Fabian Sr. is 'our' Stephen Fabian.--Dirk P Broer 19:30, 4 January 2018 (EST)
I don't know if it would work, but perhaps we could simply make Stephen Fabian a pseudonym for each of the Sr. and Jr., having those be canonical. Whenever we get an instance of "Stephen Fabian", we'd have to determine which it is and make the appropriate variant. Similar to how we handle house names. I think that treatment would allow everything to be separated appropriately and appear in a meaningful way everywhere. --MartyD 10:29, 7 January 2018 (EST)

Fireside Magazine

Back last January, I stopped cataloguing Fireside because they said they were changing from a monthly magazine to a more blog-like format. But it looks like they haven't changed that much: they still publish one featured story and several shorter pieces of fiction every month, with cover date of "February 2017" or whatever; the difference is just that the stories appear one at a time interspersed with other material. I am thinking I should catalog it after all. But fiction content only, the same as with Diabolical Plots, which is also a hybrid of a blog and a monthly fiction magazine. Agreed? --Vasha 13:03, 4 January 2018 (EST)

I would say yes, continue as before until they actually do change format. ···日本穣 · 投稿 · Talk to Nihonjoe 20:20, 4 January 2018 (EST)

isfdb in the news

Rocket Stack Rank’s 2018 Campbell Award-Eligible Writers page is up now. It lists 166 short fiction writers that are eligible for the 2018 Campbell Award. "Eligibility was determined by looking up the author on ISFDB.org and doing web searches for those without an ISFDB entry." Chavey 09:57, 5 January 2018 (EST)

How could anyone possibly be considered if they didn't have an entry? Doug H 10:00, 5 January 2018 (EST)
We are not as complete, nor as current, as we wish we were. And, as an example on the "completeness" side, I believe we are more stringent on which electronic magazines we accept than the Campbell Awards are. Chavey 12:40, 5 January 2018 (EST)
Their eligibility rules are rather complex. Given that they have to examine hundreds upon hundreds of stories, it seems likely that there will be some "out of scope" works which make their authors eligible for the Campbell award.
That said, their rules mention certain "within the scope" categories which we are likely to overlook, e.g. "a short story that appeared in our large-circulation daily newspaper". Ahasuerus 14:23, 5 January 2018 (EST)
I think (hope) the contents of all genre pro magazines in 2017 have been added now. 2016 wasn't as complete. As for anthologies, I have a list of about twenty in 2017 I haven't yet added, plus who-knows-how-many I don't know about, plus lots and lots that are in the DB don't have contents...
This is a good moment to point to the Anthology and Collection Tracker and the Magazine Issue Tracker. Light-brown and white squares indicate missing information. Any of you have copies of those pubs sitting around? (2018 trackers to be posted soon!)
I am very, very pleased that our efforts are useful in this way. --Vasha 14:18, 5 January 2018 (EST)
I have been thinking about these trackers lately. They are very useful, but take time and effort to maintain. I wonder if we could generate them directly from the database the way we generate various directories, cleanup reports, etc. It would be easy to create a magazine/anthology/collection issue grid for a given year, but certain types of notes like "Has contents but they need work" would require software changes.
Perhaps we could create new Notes templates, e.g. {{CompleteContents}} and {{IncompleteContents}}, which would be used by the software to color-code cells? Ahasuerus 14:31, 5 January 2018 (EST)
I must mildly disagree with you. The purpose of the magazine tracker (especially) is to keep an ahead-of-time schedule of issues that need to be added. An automatically-generated list of issues that are in the DB wouldn't add much of anything since the table already contains links to the issue grids, and the work of marking contents complete/incomplete takes no time at all compared to the work of predicting schedules and adding issues to the DB.
As for the Anthology and Collection Tracker.... I keep a private list of all the 2017 A/Cs, including ones (lots) that aren't in the tracker because they don't contain new stories, and periodically check for additions to the list. Having that automated would indeed be helpful. But there'd have to be a way of marking an item as "not of interest" that would permanently remove it from the list. And each new item on the list would have to be examined by a human before being added to the tracker (this is something I'd really like help with--I'm currently well behind).
That's only part of the purpose of the A/C tracker, though. It also records state of completeness of the contents, and furthermore contains A/Cs that have been announced as forthcoming, to be added to the DB when/if they appear. So, complete automation impossible. --Vasha 15:05, 5 January 2018 (EST)
The idea of having complete/incomplete contents templates isn't a bad one, but there's no way that they'd be used consistently by all the people who add to the DB. Once again, someone would find themself going through everything in the grid checking for accuracy and trying to figure out what isn't in the grid. --Vasha 15:13, 5 January 2018 (EST)
I see. Well, if the magazine tracker is mostly used to keep track of forthcoming issues that are yet to be added to the database, then there is not much we can do about it on the software side. Even the most advanced software can't report on what's not there :-)
Re: the issue of automating the A/C tracker, I am thinking of a new report accessible via the Cleanup Reports menu. Unlike regular cleanup reports, it would allow its users to specify selection criteria similar to the way Advanced Search works. Here are the selection criteria that I am currently considering:
  • Year. Accepts any YYYY year.
  • Publication type. A drop-down list with the following values:
    • Collections
    • Anthologies
    • Both (Magazines can be added later)
  • Fiction contents (i.e. not COVERART/INTERIORART/ESSAYs.) A drop-down list with the following values:
    • Any
    • Present
    • None
  • Template in Notes:
    • CompleteContents
    • IncompleteContents
    • Any
    • None
This will allow editors to search for different permutations, e.g. collections/anthologies which have no contents and no relevant templates in Notes. It should make it easy to find recently added collections/anthologies which haven't had a template assigned yet. You could also select a combination of selection criteria which will replicate the functionality of the currently existing tracker etc. Ahasuerus 18:28, 5 January 2018 (EST)

(Unindent) Yes, if your proposed templates+search allowed a/cs to be assigned to the categories "complete contents" "incomplete contents," "needs contents," and "no new contents," and if it allowed juvenile works to be excluded, it would replicate most of the function of the tracker. The tracker could then be for recording forthcoming items. I would redesign it somewhat if that was its primary purpose. Must think more about this. --Vasha 18:56, 5 January 2018 (EST)

Sounds good. I have created FR 1120 to document the requirements. Ahasuerus 15:24, 8 January 2018 (EST)

Heads-up about the "Add" buttons

I am working on the following RoadMap item:

  • Move “Add Authors/Transliterated Titles/etc” buttons to the right to free up screen real estate. This will become more important with the addition of new multiply occurring fields

It's a surprisingly complex task due to the way the software is currently written. There will be multiple successive patches to get us where we want to be. I am about to deploy the first patch, which should result in no user-experienced changes. If you notice any of the "Add ..." buttons behaving in unexpected ways, please post your findings here. Ahasuerus 19:53, 5 January 2018 (EST)

The second round of changes has been deployed. The changes affected all of the "Add ..." buttons except the "Add [person]" buttons. For example, "Add Transliterated Title" was affected but "Add Author" wasn't. Once again, the changes were strictly "behind the scenes" and there should be no user-experienced changes. If any "Add" buttons do not behave as expected, please do a full Web page reload (Control-F5 in most browsers.) If that doesn't help, please post your findings here. Ahasuerus 18:21, 7 January 2018 (EST)
Another day, another patch. More behind the scenes fixes plus one new bug: invalid Web page URLs no longer generate pop-up errors, although they still get caught by the submission validation logic. The bug should be fixed in the next 24 hours. Ahasuerus 18:54, 9 January 2018 (EST)
The bug has been fixed. You may need to do a full page reload (Control-F5 in most browsers) in order for it to take effect. Ahasuerus 14:14, 10 January 2018 (EST)
Yet another patch has been installed and once again you may need to do a full page reload using Control-F5. I apologize for the hassle, but I am in the process of undoing a certain decision which was made in 2004 and which has become deeply embedded in the software over the last 14 years. Ahasuerus 21:11, 13 January 2018 (EST)

Publication merge proposal

I'm thinking that a publication merge feature would be useful. For example, for Dolphin Island by Arthur C. Clarke we have

As a feature what I'm thinking is that a merge would only be allowed if all of the fields are identical including the link to the cover image. An editor would need to consolidate the notes for example and to have the same notes on both records.

The intent of the merge would be to move primary/transient verifications from the record being deleted to the one being retained. Keep the older of the two for secondary verifications that conflict. --Marc Kupper 17:22, 10 January 2018 (EST)

I can see the value in the ability to move primary verifications of an about-to-be-deleted publication to a different pub if some of the verifiers are no longer active. However, a general purpose "Publication Merge" option can be dangerous. Perhaps we could implement the desired functionality in a different, less risky way. The first thing that comes to mind is a moderator-only option to move primary verifications to a different pub, although that too could be risky. Ahasuerus 20:21, 10 January 2018 (EST)
Agreed - it should be moderator-only or maybe even something only you can do so that we get many eyes on the records before tossing a black hole at verified publication records. The main intent is to move primary verifications in those cases where someone missed that publication record was already available and created a new one. I could see some value to being able to move secondary verifications too. --Marc Kupper 01:02, 12 January 2018 (EST)

1973 Time magazine

I know it's a long shot, but does anyone here collect old Time magazines? Specifically, the April 9, 1973 issue? You can see the cover here. ···日本穣 · 投稿 · Talk to Nihonjoe 02:23, 11 January 2018 (EST)

You can access that issue as a subscriber or pay $2.99/mo to read it. I am a subscriber, so I can look up and clip articles for you. Not too many please.--Rkihara 13:28, 11 January 2018 (EST)
Just one article: "Message from a Star...". Thanks! ···日本穣 · 投稿 · Talk to Nihonjoe 17:04, 11 January 2018 (EST)
Sent.--Rkihara 18:56, 11 January 2018 (EST)
Thanks for your help. ···日本穣 · 投稿 · Talk to Nihonjoe 01:45, 12 January 2018 (EST)

Geffen Award

In the interest of internationalization (or should that be internationalisation?), I think we should add the Geffen Award to the list. The official site is mostly in Hebrew, but there is an English version listing all the winners. The Wikipedia page also has a list of winners. ···日本穣 · 投稿 · Talk to Nihonjoe 15:42, 26 January 2018 (EST)

An award presented by a national convention is certainly eligible. Do we have editors who would be able to enter Hebrew publications? Ahasuerus 17:53, 26 January 2018 (EST)
I can copy and paste if needed, but that's about it. ···日本穣 · 投稿 · Talk to Nihonjoe 14:59, 29 January 2018 (EST)
Well, it would be easy enough to create a new award type. However, if we don't have anyone who could enter/massage the data, it would either become an "orphan" or our data would be inaccurate. Perhaps we could request outside help? Ahasuerus 09:28, 31 January 2018 (EST)
I just contacted someone in Israel who says yes, they can find someone to do it --Vasha 11:28, 31 January 2018 (EST)
Excellent, thanks! Once that person creates an account and posts here, I will create a new award type. Ahasuerus 12:09, 31 January 2018 (EST)

Can anyone here read Chinese?

There's a magazine published in China called Future Affairs Administration which is a SFWA-qualified market. Their website is mostly in Chinese (although they plan to publish in English as well as Chinese) and I can't tell if they've produced an issue yet. Can someone check this out? --Vasha 21:19, 26 January 2018 (EST)

IIRC, User:Uzume knows a fair amount of Chinese, but he is currently unavailable. He expects to be back in a few months; perhaps leave a message on his Talk page? Ahasuerus 16:07, 29 January 2018 (EST)
I looked at it and couldn't figure it out. My Chinese is very limited. ···日本穣 · 投稿 · Talk to Nihonjoe 19:12, 30 January 2018 (EST)

My Pending Edits page updated

The "My Pending Edits" page has been update to display the number of pending submissions by all users. Ahasuerus 17:39, 30 January 2018 (EST)

Does it show it if a person has no pending edits? ···日本穣 · 投稿 · Talk to Nihonjoe 18:32, 30 January 2018 (EST)
At this time it just says "No submissions present". However, I think it would be better to display the count even if there are no pending edits. Let me see... Ahasuerus 18:42, 30 January 2018 (EST)
Done. Thanks for pointing out the issue! Ahasuerus 19:04, 30 January 2018 (EST)
Looks good. This is a very helpful idea. :) ···日本穣 · 投稿 · Talk to Nihonjoe 19:11, 30 January 2018 (EST)
Yes, looks good. Thanks a lot. Jens Hitspacebar 04:09, 31 January 2018 (EST)

Duplicate Catalog ID warnings

The software has been updated as per FR 1124, "Display a warning when a catalog ID is about to be duplicated". The new warnings are supposed to work the way duplicate ISBN warnings currently work. Ahasuerus 19:48, 30 January 2018 (EST)

Thank you! -- JLaTondre (talk) 21:27, 30 January 2018 (EST)

Potential award to add: Premio Ignotus

The Premio Ignotus is the most prestigious award for published science fiction, fantasy, and horror in Spain (there are also two prestigious prizes for unpublished work, the Premio UPC and the Premio Alberto Magno). It has been awarded since 1991 by the AEFCFT (the Spanish Fantasy, Science Fiction, and Horror Association), and is voted by the members of the Association and members of the HispaCon. Works published in Spain in the previous year are eligible in the following categories (in some but not all of the categories, the work must be originally written in one of the languages of Spain and first published in Spain): best novel, best novella (17,500-40,000 words), best story, best collected work (anth/collection), best nonfiction book, best article, best illustration, best audiovisual production, best graphic novel, best work of poetry, best magazine, best foreign novel, best foreign story (includes novellas), best web site. The page: AEFCFT --Vasha 23:57, 30 January 2018 (EST)

Seems to be a natural. Would you like to go ahead with it? Stonecreek 02:18, 31 January 2018 (EST)
Sure, I volunteer to do the data entry when the award is created. 26 years x all those categories + lots of works to add = a long time. Don't expect it to be finished soon. --Vasha 11:36, 31 January 2018 (EST)
Great! I have created the award type and 10 categories. We can add/adjust categories and verbiage as needed. Ahasuerus 13:12, 31 January 2018 (EST)
How come you left out the poetry category? --Vasha 13:17, 31 January 2018 (EST)
Oops! I thought I created it, but apparently not. Sorry about that, it has been added now. Ahasuerus 13:23, 31 January 2018 (EST)
Some notes:
  • There is an award for lifetime contribution to the field (referred to as "Premio a la labor de una vida" 1991-1993, "Premio especial Gabriel" 1994-present) which is decided by the board of the AEFCFT's publishing arm, Pórtico, rather than by vote.
  • In 1993, no awards were given except for the Premio a la labor de una vida.
  • In 1992, an award was given for "Mejor obra de no ficción;" starting in 1994, the two current categories "mejor libro de ensayo" and "mejor artículo" were established.
  • In 1991 and 1992, fiction was divided into "mejor novela" and "mejor relato." I can't find what the length definitions of these categories were, although I strongly suspect that the "relato" was everything less than 40,000 words. In 1994, the "relato" category was renamed "mejor cuento" and the award went to a novella-length work. As of 1995, this category was subdivided into "novela corta" (17,500-40,000 words) and "cuento" (under 17,500).
  • Dates when the other categories were first established: illustración - 1991; novela extranjera, cuento extranjero, revista, obra poética, producción audiovisual - 1994; antología, sitio web - 2001; tebeo - 2003
--Vasha 13:52, 31 January 2018 (EST)

(unindent) Descriptions of each category:

  • Mejor novela (best novel): Fiction at least 40,000 words long, written in one of the official languages of Spain and first published in Spain.
  • Mejor novela extranjera (best foreign novel): Fiction at least 40,000 words long which was first published (in any language) outside of Spain.
  • Mejor novela corta: Fiction between 17,500 and 40,000 words long, written in one of the official languages of Spain and first published in Spain.
  • Mejor cuento: Fiction less than 17,500 words long, written in one of the official languages of Spain and first published in Spain.
  • Mejor cuento extranjera: Fiction less than 40,000 words long which was first published (in any language) outside of Spain.
  • Mejor libro de ensayo: A nonfiction book, which may have been first published either within or outside Spain.
  • Mejor artículo: A nonfiction article which has not appeared in book form, and which may have been first published either within or outside Spain.
  • Mejor antología (I think a better English name for this would be "Best Collected Work"): A book containing at least three stories, original or translated, by one or several authors.
  • Mejor obra poetica: A work of poetry of any length, written in one of the languages of Spain and first published in Spain.
  • Mejor illustración: A single image, which may have appeared in any type of publication.
  • Mejor revista: A professional, semi-professional, or amateur magazine published in Spain.
  • Mejor sitio web: A website, at least part of whose contents are in one of the official languages of Spain.
  • Mejor producción audiovisual: A work of film, television, theater, or radio produced in Spain.

--Vasha 14:23, 31 January 2018 (EST)

Thanks for looking into this! Back when the current award editing system was implemented, we limited the ability to create new award types to bureaucrats in order to minimize the likelihood of creating duplicate types. We also limited the ability to create/delete/edit award categories to moderators. However, based on what we seen over the last few years, I don't think it makes sense to prevent editors from creating "Edit Award category" submissions. I have changed the software, so next time you land on an award category page, you should be able to edit it. Let's see how well it works. Ahasuerus 16:04, 31 January 2018 (EST)
I have made a change to "Mejor libro de ensayo". It is not a continuation of "Mejor obra de no ficción" (that award went to an article the one time it was given). You should create a separate category for "Mejor obra de no ficción." Also, I think it would be better to make "Mejor relato" a separate category; this meant something different than what "Mejor cuento" means in all but one of the years that "Mejor cuento" has existed. (If that is done, I think the 1994 award should be listed in the category Mejor relato, with a note. This is always going to be somewhat confusing, no matter what we do, but I think what would be clearest would be the category names "Mejor relato/Mejor cuento (1991-1994)" and "Mejor cuento (1995-)" --Vasha 16:34, 31 January 2018 (EST)
I have created new categories for "Premio especial Gabriel - Special Gabriel Award" and "Mejor obra de no ficción - Best Nonfiction".
Re: "Mejor relato/Mejor cuento", let me make sure that I understand the eligibility rules and the terminology correctly. It looks like there were three periods:
  • 1991-1993: Mejor relato -- all short fiction works under 40,000 words were eligible
  • 1994: Mejor cuento -- ditto, i.e. all short fiction works under 40,000 words were eligible
  • 1995-: Mejor cuento -- only works under 17,500 were eligible; works between 17,500 and 40,000 words were eligible for "Mejor novela corta"
Is this correct? If it is, then perhaps we could create three categories: "Mejor relato", "Mejor cuento (1994)" and "Mejor cuento (1995-)". Ahasuerus 12:07, 1 February 2018 (EST)
Sure, makes sense. --Vasha 13:36, 1 February 2018 (EST)
OK, I think I got it, although the wording may need to be tweaked. Ahasuerus 14:59, 1 February 2018 (EST)
There is a footnote to the AEFCFT page about Gabriel Bermúdez Castillo winning the Premio al labor de un vida in 1992: "Domingo Santos fue galardonado con un premio especial de la organización de la convención denominado “Ignotus”, aunque en realidad no se trataba de un auténtico premio Ignotus" (The organizers of the [HispaCon] convention gave Dominigo Santos a special award called "Ignotus," athough in reality it wasn't an actual Ignotus Award) -- How to record this? --Vasha 13:47, 1 February 2018 (EST)
Reading the explanation:
  • Premio a la labor de una vida: Gabriel Bermúdez Castillo (simultáneamente, los organizadores de la HispaCon de Gadir’92 otorgaron un premio con el mismo nombre a Domingo Santos, pero no deben confundirse ambos galardones).
it would appear that the award given to Domingo Santos was not really a Premio Ignotus award. I guess we could either document it in notes or create a separate category just for it with an explanation of what happened. A rather peculiar case. Ahasuerus 14:59, 1 February 2018 (EST)
I suppose add a note to the '92 Premio especial as they do, and record it in the notes of Domingo Santos's author page (which I just submitted a bio to). --Vasha 15:07, 1 February 2018 (EST)
Approved and massaged. Thanks! Ahasuerus 16:35, 1 February 2018 (EST)

(unindent) A couple errata on the award page: you have two categories in display order 30, and the capitalization of HispaCon in the description needs fixing. --Vasha 17:26, 1 February 2018 (EST)

Changed, thanks. Having two categories share the same display order value is harmless as long as their eligibility years do not overlap, but we might as well make it look pretty :) Ahasuerus 18:14, 1 February 2018 (EST)

Fuzzy searching

I have been experimenting with "fuzzy searches" based on what was mentioned during this Rules and Standards discussion last week.

The idea is that the regular search logic should ignore punctuation so that a search on "Steven H. Silver" would also find "Steven H Silver". (Note that for now I am defining "punctuation" as apostrophes, single and double quotes, commas, periods and parentheses.)

I have made the requisite software changes on the development server and it looks like they do not have a significant negative impact on response times. However, I have discovered that using "fuzzy" search logic can lead to somewhat unexpected results. A name search on "h. silver", which currently finds a single author record on the main server, finds 7 records on the development server: "Judith Silverthorne", "Kenneth Silver", etc. It seems like it may be an acceptable trade-off, but I wanted to run it by everyone before deploying the changes. Ahasuerus 18:34, 1 February 2018 (EST)

I don't think those few extra search results will be a problem. What about the other issue, the question of whether authors write their first initials "X. X." or "XX"? How many extra results would be generated by ignoring spaces also? The other way to get the same result would be to change the standard for the punctuated form to "X.X." --Vasha 19:33, 1 February 2018 (EST)
At one point I tried stripping spaces as well. However, it resulted in a lot of false positives. For example, a name search on "ajm" finds 4 names on the live server. When stripping spaces, it finds 37 names. I'll have to think of a way to normalize initials when searching. Ahasuerus 20:04, 1 February 2018 (EST)
If you are going forward with this, can it be made an option? I would find the false positives annoying. -- JLaTondre (talk) 20:38, 1 February 2018 (EST)
I'd also like the ability to decide when to use fuzzy search. Annie 20:57, 1 February 2018 (EST)
There is no hurry, we can take our time figuring out the desired behavior. Perhaps a "Fuzzy" checkbox within the search box? Ahasuerus 21:22, 1 February 2018 (EST)

Ballantine's Classic Library of Science Fiction - call for volunteers

A couple of Usenet posters have pointed out that our Ballantine's Classic Library of Science Fiction listing is incomplete. For example, it's missing The Best of Leigh Brackett and The Best of Lester del Rey. Calling for volunteers to identify and add the missing publications. Ahasuerus 08:46, 2 February 2018 (EST)

Is there a full list of them somewhere? ···日本穣 · 投稿 · Talk to Nihonjoe 14:21, 2 February 2018 (EST)
It looks like the following Advanced Publication Search: Title contains "Best of" AND Publication Type is exactly COLLECTION AND Publisher contains "Del Rey" finds all of them. Ahasuerus 14:36, 2 February 2018 (EST)
Looks much better, thanks! Also, it would appear that some pubs in this series are currently entered as by "Ballantine Books" as opposed to "Del Rey / Ballantine" -- e.g., see http://www.isfdb.org/cgi-bin/pl.cgi?407039. Ahasuerus 10:05, 3 February 2018 (EST)
The Lovecraft books do not belong in this series. The full list of books in the series is printed in the front on the later editions. The switch from Ballantine to Del Rey happened somewhere in the middle of the series. The label on the list of title went from "Ballantine's Classic Library of Science Fiction" to "Critically Acclaimed Series of Classic Science Fiction" once the publisher changed to Del Rey. TAWeiss 22:09, 2 March 2018 (EST)

Nominating user Boskar for moderator

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

I would like to nominate user Boskar (talk) for moderator, with the understanding that he would limit his approvals in the beginning to his own edits, as brought up as a general proposal in the third discussional paragraph of this item. Boskar has proofed to manage all of the intricacies that are mandatory for his submissions of German and international publications & titles of all kinds of types. He has been very careful in handling them, and has proven good communication skills whenever it was necessary. So I think he meets the Moderator Qualifications and he has accepted the nomination. Stonecreek 06:58, 3 February 2018 (EST)


Support

  1. Support, as nominator. Stonecreek 06:58, 3 February 2018 (EST)
  2. Support. No objections on the self-moderation front. I have not run into any issues with his submissions in over a year. --MartyD 11:51, 3 February 2018 (EST)
  3. Support. No objections as well. The number of submissions I've handled since I've become a moderator myself just a few months ago isn't huge, but the ones I did handle were of good quality. Jens Hitspacebar 11:19, 4 February 2018 (EST)
  4. Support. No objections - I cannot remember even one issue with his submissions in the last months. Although I will miss the German practice I was getting while following his submissions :) Annie 18:52, 5 February 2018 (EST)

Oppose


Comments/ Neutral

  1. Neutral. I have only handled a few submissions by Boskar. If I remember correctly, they were OK, but I don't have enough experience with them to vote one way or the other. I suspect that it may become a more common scenario as the number of editors and moderators grows and contributions become more specialized. Ahasuerus 09:47, 3 February 2018 (EST)
  2. Neutral. Neutral, no experience with his submissions.--Rkihara 12:14, 4 February 2018 (EST)
  3. Neutral. As far as I know, I haven't dealt with any of his submissions. From what I've seen of his posts, he seems solid. ···日本穣 · 投稿 · Talk to Nihonjoe 14:23, 5 February 2018 (EST)
  4. Neutral. I have no experience with his submissions. I see no issues on his talkpage, so positively neutral. --Willem 16:33, 7 February 2018 (EST)
  5. Neutral. I've not had experience of his submissions. PeteYoung 16:37, 7 February 2018 (EST)

Outcome The nomination passes. The moderator flag has been set on Boskar's account and he should be able to approve his own submissions going forward. Ahasuerus 11:50, 9 February 2018 (EST)

Edit form changes - Part 2

I am in the process of working on another round of edit form changes. Like the last round, it shouldn't affect the behavior of the edit forms. If some of the "Add" buttons appear to stop working, please do a complete page reload (usually Control-F5). If that doesn't help, please post your findings here. Ahasuerus 16:27, 3 February 2018 (EST)

Another day -- another patch -- same patch notes as above. Ahasuerus 17:10, 4 February 2018 (EST)
Yet another day, yet another patch. Same drill. Ahasuerus 13:36, 5 February 2018 (EST)
Another patch, which changed the way the "Cover Art" section of New Publication submissions is handled behind the scenes. If you see anything unusual and Control-F5 doesn't fix, please let me know. Ahasuerus 17:47, 5 February 2018 (EST)
The changes to the Cover Art section which were started yesterday have been completed. There should be no editor-experienced changes. Ahasuerus 15:45, 6 February 2018 (EST)
Yet another patch has been installed. It affected the rest of the Content section. As before, there should be no user-experienced changes. If you see anything unusual and Control-F5 doesn't fix, please let me know. (With luck, I hope to be able to wrap up these annoying tweaks in the next few patches.) Ahasuerus 12:04, 7 February 2018 (EST)

(unindent) It looks like the last patch introduced a new bug which makes editing most pubs impossible. Investigating... Ahasuerus 12:41, 7 February 2018 (EST)

The immediate bug has been fixed. Some types of pop-up validation are currently unavailable, but it shouldn't prevent editors from creating submissions. Working on it... Ahasuerus 12:55, 7 February 2018 (EST)
OK, the pop-up validation should be fixed now. Sorry about that! Ahasuerus 13:54, 7 February 2018 (EST)
Yet another patch has been installed. We are getting closer to the finish line. Ahasuerus 17:49, 7 February 2018 (EST)
A big patch was installed a few minutes ago. The same rules -- if you see anything unusual and Control-F5 doesn't fix, please let me know -- apply. There is some additional cleanup that will need to be done over the next couple of days, but the bulk of the changes is now live. Ahasuerus 14:34, 9 February 2018 (EST)

New Mistakes

I just submitted the ebook version of Year's Best Hardcore Horror: Volume 2 to this site. I had to copy the contents off of Amazon by hand, and, of course, I made a few spelling mistakes. If my submission is accepted, I will correct the misspellings of the authors Michael A. Arnzen, Eric LaRocca, Jasper Bark, and Adam Cesare. I am so ashamed. MLB 20:34, 8 February 2018 (EST)

Say three "Hail Fixer's" and you will be absolved of this sin. It's been approved. ···日本穣 · 投稿 · Talk to Nihonjoe 20:40, 8 February 2018 (EST)

Udon Entertainment Japanese art portfolios

I picked up a couple of these some time back. Specifically this and this and these seems to be a plethora of these game related art portfolios. I sounded Hauck out about the validity (or not) of entering these kinds of publications. His reply to my query about computer game art portfolios was (quoted verabtim):

Hello, my understanding is that we're a "fiction" database, "fiction" seemingly taken in the implicit sense of "written". Note also that by our ROA, comics are explicitely out, so are graphic novels. For art books, my answer would be the same, they shouldn't included. Striking a blow to clarity, in the case of SFF artists, huge numbers of them (complete art books) have been entered (like here), that may have had some bibliographical justification at the time (to identify some covers) but then there was another slip and such portfolios were also entered (even if their relation to spec fic was nil). AFAIC, I'm strictly against inclusion of non-mainly-written-spec-fic items, including the portfolios that you evoke. To be a database of comics, "bandes dessinées", portfolios, artworks, even if SF-themed is, IMHO, not our present project. We can't (and don't want to) compete with such sites. But, as there is no pilot in the cockpit and we are in a time where any submission has a chance to be accepted regardless of its pertinence, you can try your luck, I won't reject your submissions. Remember that all this is just a personal rant, so perhaps can you bring the matter to one of our common spaces (even if this will be without me).

Some of these computer game art portfolios are already included in ISFDB - eg this which has a limited edition version (and probably numerous others.

I know there will be the "purists" (not a bad thing and not meant as an insult) who will have the view that none of these publications should be included - even art portfolios for well known SF artists like Chris Foss etc.

Would there be a definitive answer as to what material of this nature would/should be allowed or will it come down to the individual moderator.

I stated to Hauck that "I'll take my chances and if they're rejected then I'll accept that and move on."

Your thought/rants/comments.--Mavmaramis 14:18, 9 February 2018 (EST)

I have entered I think hundreds of SF/F art books, although none that are game-based. One thing I noticed though, is that Spectrum 24 contains significantly more game-related artwork in the "Books" category than earlier volumes of Sectrum, and it seems to outnumber the cover and interior art examples. SF/F artists seem to be making a larger fraction of their income from games than they used to. Obviously, I'm an advocate of art books and portfolios by noted fantasy artists, but I would not include game-based or movie-based art books unless the artist is also noted for illustrating genre books. But of course, I'm not a moderator. Bob 17:11, 9 February 2018 (EST)
I think that sf/f/h art books ought to be included, regardless of whether the person is known for illustrating genre books or magazines. Keep in mind that many of the artists who do game design and art in Japan (speaking to this example in particular) also regularly do sf/f/h magazine and book covers and interior illustrations. A very large percentage of them (far higher than in the States). ···日本穣 · 投稿 · Talk to Nihonjoe 18:25, 9 February 2018 (EST)
Also, there are a number of Hatsune Miku novels out, too, and since she's basically science fiction, I think she's in no matter what for novels and art books. ···日本穣 · 投稿 · Talk to Nihonjoe 18:27, 9 February 2018 (EST)

proposed canonical name change: Standish James O'Grady

Standish James O'Grady, currently with the canonical name Luke Netterville, should probably be changed to O'Grady, as this was both his usual name and the one under which he published some fairly-well-known children's fantasies. Netterville was his pseudonym for a single obscure science fiction novel. He is in SFE3 as O'Grady.

I have already changed "Dr. Douglas Hyde" to the more commonly used form Douglas Hyde. --Vasha 07:32, 11 February 2018 (EST)

Yes, as I processed some of your submissions, I had the same thought about O'Grady vs. Netterville. --MartyD 06:07, 12 February 2018 (EST)
All done. --Vasha 17:58, 12 February 2018 (EST)

Robert Anton Wilson

We have an editor wishing to add Robert Anton Wilson's non-fiction work which is non-genre. What is the community thought on Wilson's threshold status for non-genre works? -- JLaTondre (talk) 18:00, 11 February 2018 (EST)

Hi, I added a few books because I saw there were a number of his other non-fiction works already listed - including a few (Prometheus Rising, Ishtar Rising, the three Cosmic Trigger books) erroneously listed as novels. Bob is a strange case - his truest Science Fiction series was the Schrodinger's Cat trilogy, which dealt with multiple dimensions. His Illuminatus Trilogy and related works are sometimes considered science fiction for want of a better category. His non-fiction work is highly speculative and touches on many issues related to science fiction - space travel and life extension, in particular. --Donnachadelong 18:09, 11 February 2018 (EST)
Note that The Illuminati Papers is already in the database.--Dirk P Broer 10:54, 13 February 2018 (EST)

Since there has been no input, I'll remove the hold on these and leave it to another moderator. I'm not convinced Wilson is above the threshold, but would prefer to not to take unilateral action given the varying thoughts on this manner. -- JLaTondre (talk) 21:09, 14 February 2018 (EST)

Verification for scans, PDFs, etc.

I want to second Marty's proposal here: "I've been thinking that we should have some sort of "electronic copy" verification. It could encompass PDFs/OCR scans, Look Inside, Google Books, and perhaps others. In fact, maybe each ought to be its own separate item (since, for example, Look Inside is partial, while a PDF might be the full publication). Actually confirming facts out of one of these things often will be as good as, or better than, secondhand information from some of our other secondary sources. Yes, it's a little tricky to make sure the electronic copy represents the same publication and edition, but it still seems worthwhile, and the cost of someone goofing up such a verification is low."

Currently when I have entered data from an online scanned copy I mark this as a transient verification. I know some other people mark it as a permanent variation, and still others as not a verification. It would be nice to have a solid way of recording this. It should go along with a way of linking to the scan on Google Books, Archive.org, Hathi Trust, etc. --Vasha 13:51, 13 February 2018 (EST)

I think it's a worthwhile idea. Let's consider how we can implement it within the existing framework of primary and secondary verifications. Let's review the current functionality:
Primary verifications are subdivided into "Permanent" and "Transient". Any number of users can primary-verify a publication, but a user can only choose one primary verification sub-type. If you choose "Permanent", you can't choose "Transient" and vice versa.
Secondary verifications are "reference"-specific: Locus1, OCLC, etc. A publication can be "secondary-verified" against a reference by one and only one user. For example, once a pub has been verified against Locus1 by a user, no one else can do it.
The important distinctions are:
  • Primary verifications allow multiple users to verify the same publication while secondary verifications allow only one user verification per pub per reference.
  • Secondary verifications support multiple references per pub while primary verifications are generic.
Given these limitations, let's consider whether electronic verifications are more like primary verifications or more like secondary verifications. I guess it depends on the specific functionality that e-verifications will need to support. If the priority is to allow multiple users to e-verify the same publication, then we could add an "Electronic" sub-type to Primary verifications. If, on the other hand, the priority is to support multiple references like Google Books, Archive.org, and Hathi Trust, then we could add them to the list of supported references.
I think there is another 'source' that could/would be misused terribly: Amazon. If these scan/electronic verifications get into the Primary end, anyone could go through a zillion Kindle 'editions' and claim to have verified them when they aren't [other than having a reader and thus the whole text] any more than a couple of pages, no data at all [page count/price/ISBN/ASIN] are only noted in the amazon 'record' and are of course totally unreliable. Amazon can never, ever become a verification source for anything [might as well start using blogs .....]. By keeping these site-specific [thus secondary] that can't happen. As for those who do Primary V's from scans, just not right. The book has never been in their hands. Transient even stretches the point. However, the electronic side is here to stay, so needs to be addressed in some way. --~ Bill, Bluesman 20:25, 1 March 2018 (EST)
As far as linking to Google Books, Archive.org, Hathi Trust, etc goes, the current verification system doesn't support linking to other Web sites. We do have a couple of options, though:
  • Third party sites which allow linking by ID can be easily added as "external identifiers".
  • Third party sites which do not support linking by ID and require an explicit URL can't be supported at this time. However, we can support them once we implement FR 957, "Add a repeatable "Web Pages" field to Publication records".
Ahasuerus 16:03, 15 February 2018 (EST)
If treated as a secondary verification, there still only needs to be single "Electronic" (perhaps "Scan" would be better as eBooks are electronic also) type. Hathi Trust hosts the Google scans from university libraries so many (most?) times they are the same copies as Google Books. I'm not sure, but I'm under the impression that Archive.org copies the Google scans also. So in the end, there is only one source for many of these. While those are the main sites, there are plenty of other sources out there (I've seen authors host them on their website). A single type and stating the source in the pub notes should be sufficient. For sites without stable IDs and links, URLs can continue to be embedded in the notes via HTML before FR 957 is implemented. -- JLaTondre (talk) 19:44, 15 February 2018 (EST)

Harry Farjeon's "Exit"

This Usenet question revealed that we are missing Harry Farjeon's SF story "Exit" and the 2000 collection "That untravelled world: a collection of science fiction short stories". Looking for volunteers to do more digging and enter the missing data. Ahasuerus 14:37, 13 February 2018 (EST)

Edit form changes - Part 3

Yet another round of edit form changes has been deployed. Like the previous rounds, it shouldn't affect the behavior of the edit forms. If some of the "Add" buttons appear to stop working, please do a complete page reload (usually Control-F5). If that doesn't help, please post your findings here. Ahasuerus 16:07, 13 February 2018 (EST)

A new patch has been deployed. It shouldn't require Control-F5. Ahasuerus 18:34, 13 February 2018 (EST)
Another patch has been deployed. Ahasuerus 22:53, 15 February 2018 (EST)
Yet another patch has been deployed. It revamped the way "Edit Title" works behind the scenes and made the following quality of life changes:
  • The submission review page displays all authors, including reviewed and interviewed authors, at the top of the page instead of at the bottom
  • Blank fields for multiply occurring values (authors, transliterated titles, Web pages, etc) only appear when requested, which should save "screen real estate"
Ahasuerus 15:58, 16 February 2018 (EST)
An additional, hopefully completely transparent, patch has been installed. Ahasuerus 19:16, 16 February 2018 (EST)

(unindent) A new patch has been installed. Unlike the last few patches, it may require a Control-F5 reload (depending on your browser settings.) Ahasuerus 14:46, 17 February 2018 (EST)

Canonical name change: Alfred Tennyson

I don't know why Tennyson stil has the (incorrect!) name "Lord Alfred Tennyson" at the top of his page but a look at the page shows that "Alfred Tennyson" by far the commonest name-variant encountered. I will change it tomorrow if no one objects.

Also, it turns out that although "William Butler Yeats" is the canonical name, there's only 12 titles using that pseudonym versus 72 for "W. B. Yeats"! I knew the latter was commoner but didn't realize the difference was that much. Should we change it? --Vasha 20:26, 18 February 2018 (EST)

Tennyson is done. I guess if no one has anything to say about Yeats, I'll change the canonical form to "W. B." in a few days. --Vasha 18:40, 19 February 2018 (EST)
Sounds good to me. ···日本穣 · 投稿 · Talk to Nihonjoe 20:37, 19 February 2018 (EST)

"Black author" tag

(Moved from [here])

Hello, I'm voicing here my concern about this tag. Here (in France) we're quite touchy about questions of privacy and of data gathering. In a nutshell, to enter and/or to store and/or to give public access to data about the racial characteristics of an individual (or his/her sexual orientation or political opinion) is simply illegal and may be severely punished. I know we're not a french-law-abiding outfit but, to be frank, I'm quite ashamed to be associated with such an endeavour. Why not add such tags as "Muslim", "Leftist", "Gay", "Have cancer", "Of short heigth", "Redhead" etc... (I spare you the Godwin point "To be eliminated") It is the same for Afro-american and even the fact of passing the tag to "private" is not enough (for me and the french law, perhaps the european one), it's the simple constitution of a database with names that is illegal without it being declared. I was already quite worried about our forays into gender typification, but this is worse. Hauck 04:20, 23 February 2018 (EST)

The same is valid for 'African author' and likely some others. In addition to the things Hervé wrote, these labels totally ignore that tags are for titles, and not for authors: it may be okay to have 'Black protagonist', but no thing in this vein to stigmatize authors. Stonecreek 05:08, 23 February 2018 (EST)
I hear your concerns. I started that project last year because of the #BlackSpecFic report. People there were tracking where black authors got published and I wanted to help them. (I was thinking of contributing to Wole Talabi's list of African spec fix also but I never did much with that.) So you think it is not appropriate to do that tracking in a public manner? --Vasha 08:18, 23 February 2018 (EST)
I think it's totally contra-productive. It really smears all relevant information on thematical issues for an author like Samuel R. Delany to have 153 times characterized him as 'Black Author' (who would have thought that?). It has next to no thematic relevance, and I think this is the case for most authors characterized so or in a similar way. Who wants his works issued by color of his skin? Stonecreek 08:39, 23 February 2018 (EST)
The idea is not to tag the author but rather to get an idea of where and when works by black authors have been published--would it sound better to you to change that tag to "work by Black author"? Also, I am in touch with a couple of the people involved in #BlackSpecFic and if you like I could ask them whether they think it is useful or appropriate to use the database in this way.
I would also like to ask Darrah because of her experience trying to use the database to study women Writers. And I know she's given a lot of thought to privacy concerns. Unfortunately she's not around now. --Vasha 08:46, 23 February 2018 (EST)
No, this is a meaningless tag for our purposes. I really think it has to be deleted, or, if that's not possible, to mark it as 'Private'. You really seem to do some things without thinking them through: that's called actionism. A title tag has not to be misused as an author tag: and these examples seem to be a kind of putting authors into a drawing-box, and nobody has asked them if they want to be put in there. Stonecreek 09:03, 23 February 2018 (EST)

2016 #BlackSpecFic report. See surrounding discussion for why it is unfortunately necessary to talk about writers' race. It is not at all irrelevant to their chances of being published; it is the publishing industry that puts people into boxes. --Vasha 09:17, 23 February 2018 (EST)

We're not here to record the plight of black writers. Such tags attached to persons are simply unacceptable and may even be libelous. As for Darrah (who's a he), this page is IMHO already borderline. Both of you can make all the lists of black or feminine or transgenre or martian writers you want but you simply can NOT use the ISFDB which is a public space. Hauck 10:35, 23 February 2018 (EST)
This conclusion has been proven false, if not dangerous. Opening trenches between black / white or Jewish / Arian or any other thought-of dividing line between people has been never a tremendously good idea. You need to talk about the issues & sources of racism, and that what's literature for (foremost I think). But this can only be adressed in works, not by hammering differences into heads by showing this is the most important thing for a given author.
Also, you seem to flea the basic fault of the misuse of tags. Stonecreek 10:20, 23 February 2018 (EST)


(unindent) It looks like there are a number of issues here, including:

  1. The legality of certain tags
  2. The ISFDB software design which currently lets users add tags without moderator approval/oversight (potential accuracy issues)
  3. The ISFDB policy which determines which tags are made "Private" by moderators
  4. The feasibility of using title-level tags to enter author-specific data ("female author", "indie author", "Finnish author", etc)

As previously discussed, the laws that we have to abide by are the laws of the jurisdiction where the ISFDB server is currently located. (It's the same for projects like Project Gutenberg whose servers host different works depending on the country where each server is located.) There may be libel laws that we have to abide by, e.g. "written by a thief and a murderer" could be an issue, but at this time our data entry policies are not legally constrained otherwise. --Ahasuerus 10:41, 23 February 2018 (EST)

To reply to point four, is it really author-level data when you say "this particulat work was written by an Irish author"? Because that's how I intended it & maybe the name of the tag should be changed to make it more clear.
To the rest, I really want to hear from people! --Vasha 12:07, 23 February 2018 (EST)
I hope to provide some background info re: tags when I get back to my evil lair of evil secure undisclosed location later today. Ahasuerus 13:09, 23 February 2018 (EST)
Black for an American audience is not the same as black for a Brazilian one for example. Nationality is one thing. Colors and genders are a different thing. And I do not think we should be in the business of tagging people with colors (and genders - there is a reason why the last proposal to add gender to the DB was shot down again) - what percentage of your blood should come from black ancestors so you can be considered black? We are a FICTION cataloging site, let's not go around and put labels to people. Tagging works is ok based on the content of the text; tagging works based on author's characteristics has no place here in my book.
Even if something is legal, it may not be the correct thing for an international community as ours. The only question we should care about is if an author writes in our genres. I understand that some people may want to do research based on race and what's not but where do we stop? Just my 2 cents. Annie 14:46, 23 February 2018 (EST)
I know it's anathema to some people, but I couldn't care less about an author's race, gender, politics, sexual preference, or whatever else. I read fiction because the story interests me. Therefore, I see no valid reason to include tags that catalog those things here. ···日本穣 · 投稿 · Talk to Nihonjoe 15:09, 23 February 2018 (EST)
These last two posts sum it up perfectly. We need to stop where the genre stops. That is the underlying definition/reason for the existence of this database. --~ Bill, Bluesman 20:08, 1 March 2018 (EST)

Using author information in title tags

Let's consider the larger issue of entering author-specific information via title tags. As previously indicated, we have tags like "indie author", "African author", "Finnish author", "Black author" and "female author". It seems clear that the reason they have been created is that we have no support for author tags and no structured way to enter this data in author records, which is why our editors who want to see this information recorded use title tags as a crutch.

I think this raises a number of potential issues:

  1. At least one of these tags ("female author") is effectively used to get around the fact that we have not been able to reach consensus re: adding a "Gender" field to author records.
  2. Some of these tags are inherently complex and ambiguous, e.g. "African author" -- consider the multi-faceted definition used by the Nommo Awards for African Speculative Fiction to determine who is and who isn't an "African author" for their purposes.
  3. If and when the tagged title's author(s) are disambiguated, author-specific tags may become invalid. For example, if we determine that the name "J. Smith" has been used by two people, "Joan Smith" and "John Smith", and move some of the titles to "J. Smith (I)", some author-specific tags may be moved to the wrong author.
  4. If our information about an author changes due to more in-depth research or because the author's circumstances have changed (e.g. an author may have published her first book as an "indie author" 10 years ago, but has been traditionally published since then), we'll need to go back and change a bunch of tags. Given that tags are editor-specific, it may not be easy to do if the tagger is unavailable.

Given these concerns, I think it may be prudent to make it our policy that all author-specific tags should be made "Private" by moderators. Editors will still be able to use them to compile lists of works by certain categories of authors for their own purposes. Ahasuerus 16:23, 23 February 2018 (EST)

I'm fine with that. Is there a way to exclude them from tag searches by default, or are private tags already excluded by default? ···日本穣 · 投稿 · Talk to Nihonjoe 17:32, 23 February 2018 (EST)
Private tags are currently displayed in search results, but they are marked "Private". Ahasuerus 17:38, 23 February 2018 (EST)
That should definitely be changed, they shouldn't be displayed. --Vasha 15:12, 25 February 2018 (EST)
Scratch that, due to the comment about searching below. --Vasha 16:18, 25 February 2018 (EST)
I fully support that. Any chance to change the default of tags so that any tag is private when created and need a moderator to make it public? (I had never used the tags system so not sure how it works now). Annie 17:35, 23 February 2018 (EST)
Hm. An interesting thought. It would be easy to make all new tags "private" by default, but the way the database is currently structured, there is no easy way to create a report of "recently added tags which need to be reviewed by a moderator". I'll have to think about this some more. It may be something to consider if we decide to implement FR 911 "Allow moderators to edit and merge tags". Ahasuerus 17:44, 23 February 2018 (EST)
Put it on the editors to ask for a tag to be made public? This way we do not need to actively monitor for new ones - and as long as the help is very clear that this is the case, any editor that wants to tag will know how to ask. I do not know what is the volume of tags we have in the system and how many new ones (not adding existing tags to new works) are added daily or weekly but I doubt that it is more than the number of images... or anywhere near that. Just thinking aloud. Annie 17:50, 23 February 2018 (EST)
Is it possible for Private tags to be visible to more than one person? because I've had at least one person tell me that the author-related tags I did would be very useful to them. --Vasha 14:01, 25 February 2018 (EST)
If you know the spelling of a "private" tag, you can search for it, which will take you to a list of all titles associated with the tag. For example, here is a list of the 326 titles tagged "Read17". If you click the number next to each tagger's username, the list will be limited to the titles tagged by that user. (Irrelevant when the tag is used by only one user, but potentially useful when multiple users are involved.) Note that if you follow a hyperlink to a title, private tags won't be displayed on the title page. Ahasuerus 16:14, 25 February 2018 (EST)
I can't imagine anybody who wouldn't be distracted by 153 times Black Author from any thematic relevant items. Stonecreek 14:16, 25 February 2018 (EST)

(unindent)I have just one thing to say: such tags that characterize individuals based upon their race, gender, beliefs, political opinions, etc... are judgemental, offensive and as they are hosted by our community they commit our collective responsability. This is not a question of technic (author-related tags vs. text-related tags), this is a question of ethic and morality. Who has allowed some contributors to write in our bibliographical database of another human that he/she's "black" and who confered to some contributors the moral right to make a list of "Blacks" (be it public, private, or semi-private). Of course, this is also the case with "White", "Zoophile", "Brunette", "Communist", "Lesbian", "Copt", "Plump", "Autistic", etc... To answer the last post I striclty don't care if someone find this useful, as I'm sure that the KKK would have the same opinion.Hauck 14:27, 25 February 2018 (EST)

I think you are missing some important points but this is not the place to argue general issues such as whether it is or is not offensive to refer to people who self-identify as Black in that manner. --Vasha 14:31, 25 February 2018 (EST)
Re: "this is a question of ethic and morality", I see it as, first and foremost, a process issue. In addition to our core bibliographical data, the database contains a certain amount of publicly available biographical data: dates of birth and death, places of birth, Web pages, etc. If an editor would like to have additional fields added to Author records, the standard way to do it would be to post a proposal on the Community Portal or on the Rules and Standards page. That's what happened with the proposal to add a "Gender" field, which has been debated a few times. Similarly, an editor could suggest adding software support for "author tags" which would be similar to title tags. Then it would be up to the community to discuss the proposal, debate its merits and see if we can reach consensus. Even if it doesn't look like there is much community support for a proposal, you never know what a discussion may lead to -- certain past discussions started with a request to implement Feature A, but we ended up implementing Feature B instead.
Given that tags do not use the standard moderation system, they give editors more flexibility than other parts of our editing software. This is no accident -- back when tags became popular on the Web (Amazon, later Goodreads, etc), they were a brand new addition to the tool set given to users, so we decided not to put any constrains on them and see what would happen. Over time, some users began using tags to create reading lists, which is similar to the way Goodreads users leverage them. Our response was to add the ability to make tags "Private", which addressed that issue. Now we are facing another issue, "author-specific tags", and need to decide how to address it. Ahasuerus 15:34, 25 February 2018 (EST)

Proposed Help changes

Based on the discussion above, the consensus is that author-specific tags should not be displayed on bibliographic pages. I would like to propose a change to the relevant Help page. The current version says:

  • Most tags are descriptive, e.g. "space opera", "time travel", "alien invasion", etc. You can also assign tags to create personal lists like "read list", "verification list", etc, but moderators may change the status of such tags to "private". Private tags can only be seen by the tagger.

Here is the proposed language:

  • Tags are used to enter:
    • genres
    • subgenres
    • non-spoiler plot elements
    • other objective, non-judgemental information about a title
  • Tags that are not about the title or otherwise do not comply with these guidelines will have their status changed to "Private" by the moderators. Private tags can only be seen by the tagger.

How does it sound? Ahasuerus 16:25, 1 March 2018 (EST)

I presume that "other objective, non-judgmental information about the title" is intended to make it so that, for example, a tag saying that the book appared on so-and-so's best-of list isn't private. But this statement does need to be more specific and detailed. What if someone wants a tag for all the works discussed in Fennell's Irish Science Fiction? You will have to make explicit that tags which deal with the national origin or other background characteristics of the work should be private. It is objective to say that the work was discussed by Fennell; would it be not-private to tag the work "Fennell" but private to tag it "Irish science fiction"? --Vasha 17:03, 1 March 2018 (EST)
I was primarily thinking of tags like "This is not SF but a good read" [sic!]. Tags like "Merril01" and "Million Writers Award winner" would remain public under the new, clarified system because they are title-specific, objective and non-judgemental. I assume that tags for SF titles listed in "[Country/continent/etc] SF" books would also remain public. Ahasuerus 17:34, 1 March 2018 (EST)
That's fine! But the vague language you proposed doesn't make that clear, nor does it help resolve the current case-in-point debate. Where (if at all) is there a line drawn between 1. Works tagged "Discussed in Fennell's Irish Science Fiction" 2. Works in Fennell tagged "Irish science fiction." 3. Works not specifically mentioned in Fennell, but by Irish authors, tagged "Irish science fiction." 3. Works tagged "by Irish author" or "Irish author." -- How does the answer to these questions apply to works mentioned in Saulson's 100+ Black Women in Horror? --Vasha 19:28, 1 March 2018 (EST)
Drawing infinite lines in the sand aside, you still can't seem to understand where they get crossed. If it was up to me ALL tags would be gone. They serve no bibliographic purpose. However, if an author is of Irish descent his/her author page will note where he/she was born. Can't be said of "Black Women" authors though, can it? Thus judgemental. Our only purpose here is to catalog the works. The sub-sub-sub .... categorizations you seem hell-bent on just don't matter ... here. By our own definitions this database is limited, and it's has to stay that way, evolving as necessary. You keep pushing for things that are ethically, morally and possibly legally wrong. Try backing off a pace or two and thinking. --~ Bill, Bluesman 21:06, 1 March 2018 (EST)
Talking about authors in a racial context is by no means unethical in all circumstances, such as in Saulson's book and many other discussions. However, the point that the ISFDB is extemely limited and cautious is a valid one. I can see where tagging introduces unwanted complications to the basic bibliographic purpose of the database. Where and when a book was published, and what is printed on its title page, are absolutely unambiguous facts. Author information (date/place of birth) could potentially be regarded as primarily a way of distinguishing different authors. However, the database does contain much more than that; the horse has left the stable. People keep wanting to add more: author bios & photos, awards, tags to distinguish genres, tags for themes... People will be wanting tags in order for the database to help them with various projects, including the #BlackSpecFic project, and that is an extension of the original purpose which raises problems. I am sympathetic to the notion of having no tags at all... Back to basics? --Vasha 21:46, 1 March 2018 (EST)
Let me take a step back and point out that library catalogs have been using "subjects", which are similar to our title tags, for generations. For example, this Library of Congress Catalog entry lists the following subjects associated with War of the Worlds: Global Dispatches:
  • Science fiction, American
  • Imaginary wars and battles--Fiction
  • War stories, American
  • Mars (Planet)--Fiction
If you click one of these subject headings, you will be taken to a list of all catalog entries for that subject. That's the basic functionality that we tried to replicate when we added tags to the ISFDB tool set ca. 2007. Of course, we are a more specialized project, so we have more specialized tags in addition to generic "fantasy", "science fiction", "horror", etc tags. I find them to be very helpful and have used them 59114 (sic) times while working on Fixer's additions to the database.
As discussed earlier, we realized that tags would most likely be also used for other things even though we didn't know exactly what those "things" would be. (It's just the nature of data elements whose values are not constrained by software designers.) If you look at the way tags are used at Goodreads, which doesn't restrict tags as much as we do, you'll find all kinds of things: "dnf" ("did not finish"), "favorite", "wishlist", "recommended", "i-own", "kindle-books", "reread", "book-club", "author-male", "disappointing", etc.
As it turned out, tags were convenient when working on various bibliographic projects, e.g. entering all books mentioned in a particular secondary bibliography or finding certain works nominated for obscure awards which we do not support. Later on, some users began leveraging them to create their own reading lists, which prompted the creation of "private" tags.
Another thing to consider is that removing previously implemented, established functionality, especially removing user-entered data from the database, is very bad for morale. Some users have spent dozens if not hundreds of hours researching tag information and adding it to the database. They would be very upset if the data suddenly disappeared.
BTW, this is why I tend to be cautious about expanding the scope of the project -- once you have added support for new data elements or new functionality, it can be very difficult to go back without stepping on someone's toes and possibly losing editors. Ahasuerus 00:03, 2 March 2018 (EST)
I think these help changes are good. However, the sentence "other objective, non-judgemental information about a title" may be a bit too abstract for new editors who didn't read this discussion. Some people may even believe that "black author" is an "objective" attribution. I haven't come up with a better wording yet, though, but I'll let it roll around in my head a little bit. Jens Hitspacebar 11:24, 2 March 2018 (EST)

Alternative approach: Subjects vs. Tags

After rereading the discussion of "subjects" and "tags" above, it occurs to me that there may be another way of approaching this issue.

We could change our software to separate objective "subjects", which are used by library catalogs and roughly correspond to genres and sub-genres, from subjective "tags". "Subjects" would then be entered via the Edit Title page and be part of regular EditTitle submissions reviewed by moderators. Subjects won't be user-specific. The majority of public tags would be auto-converted to "subjects". The remaining public tags would be made private and would only be visible to their owners.

The advantages of this approach are:

  • Moderator oversight will ensure enhanced accuracy
  • Tag duplication ("werewolves" vs. "werewolf") will be reduced if not eliminated
  • Moderators will no longer have to worry about identifying newly created tags and possibly making them private

The disadvantages are as follows:

  • More submissions and more work for moderators
  • Editors will have to wait for their submissions to be processed

There may be more to it, but that's all I can think of at the moment. Ahasuerus 11:20, 2 March 2018 (EST)

Sounds good, except for the amount of upcoming work. Would it be possible to allow the moderating only for new tags / subjects (provided they are non-Private)? Stonecreek 11:39, 2 March 2018 (EST)
Let me first clarify that once all "objective" tags have been converted to "subjects", the remaining tags will be private and won't need to be moderated. Users will continue to be able to use them just like they use them now except that all of them will be private.
Re: making it possible to add established subjects like "time travel" to titles without moderation, I'll have to think about it. There are some issues that will need to be considered, but it may be possible. Ahasuerus 11:58, 2 March 2018 (EST)
It's a good idea, but yeah, a lot of work. I think tidying up the current chaos of tags would be good for the database. One thing that increases the amount of work is that not all possible subject tags exist yet. I just read a story where palm reading was an important element throughout, and that term isn't a tag yet; nor is "cheiromancy." So identifying and merging subjects won't be a one-time project; moderators will also have to vet submissions for new subjects, plus hopefully if someone submits "cheironancy" it'll occur to the moderator to check whether we already have "palm reading." That's probably more thinking than most people want to do when dashing off a few approvals before work! So yeah, good idea, and I hope it's workable. --Vasha 15:42, 2 March 2018 (EST)
I have been thinking about this issue for the last few days. It looks doable and I'll post the proposed design once I sort out a few things. Ahasuerus 23:38, 7 March 2018 (EST)

Proposal: special moderator-monitored page for name corrections

I have seen a repeated problem where I post a request for an author or publisher name correction on the Moderator Notice Board, it doesn't get dealt with, and then it moves up the page and is forgotten. How about this: correction requests should be posted on a page of their own so that moderators can easily see what's pending in that respect. --Vasha 13:53, 25 February 2018 (EST)

It is perhaps because you Yeats request was under a Tennyson heading?--Dirk P Broer 18:54, 25 February 2018 (EST)
That's not what I'm referring to. Rather, it is when we want something done like a diacritic added to an author's name, which is most easily done by a moderator because of the nature of the software. --Vasha 18:58, 25 February 2018 (EST)
If you want quick action: look at recent edits, so you see which moderator is currently active, and post on his/her page.--Dirk P Broer 19:02, 25 February 2018 (EST)

Show title record's language on publication page as well

Based on the discussion Rules_and_standards_discussions#Entering_translator I suggest to show the language of the title record on the publication page as well.

A good place may be next to the publication title, like this:

Publication: 2001: Odyssee im Weltraum [German]

This would be consistent with the already existing language display format for titles which are contained in a publication and which have a different language than the container title. Example: Metamorphosen, see the "Kepler" poem there, which is contained in Italian and German.

Jens Hitspacebar 10:59, 2 March 2018 (EST)

I think it would be useful to display the "reference" title's language on the Publication page. However, languages are associated with titles rather than publications, so displaying this information next to the publication title may be confusing/misleading. For collections, anthologies, etc we could display it next to the container title, but NOVEL pubs do not display the reference title in the metadata (top) section of the page.
Perhaps we could do what Marc Kupper suggested a while back and display NOVEL pubs' reference titles in the metadata section of the Publication. That way the same reference title data would always appear in the same place for all publication types and we would be able to display the language information consistently. The downside is that we would be displaying NOVEL titles twice, once in the metadata section and then again in the Contents section. Ahasuerus 12:09, 2 March 2018 (EST)
I initially thought it'd be more intuitive for casual users to see the language next to the publication's name. But you're right, this would mix title record and publication record data in an unusual way. We could get rid of the NOVELs being displayed twice in the following way:
  • Move the "Container Title" information for ANTHOLOGY, COLLECTION, CHAPBOOK, NONFICTION and so on down to the "Contents" section, but above the word "Contents", and show the language of these titles there
  • For NOVELs, show the language next to the novel's title in the "Contents" section.
Example for a collection:
Container Title: Andere Himmel [German] • collection by China Miéville (trans. of Looking for Jake: Stories 2005)

Contents (view Concise Listing)

• Suche Jake • short story by China Miéville (trans. of Looking for Jake 1998)

Example for a novel:
Contents (view Concise Listing)

• 2001: Odyssee im Weltraum [German] • [A Space Odyssey • 1] • novel by Arthur C. Clarke (trans. of 2001: A Space Odyssey 1968)

I think that's also more consistent regarding title record and publication record separation, because the topmost section will become free of title record information then, and the "Contents" section, which contains the title records, will also contain the container title record information. Jens Hitspacebar 12:18, 3 March 2018 (EST)
I like the idea of moving the "container" line to the Contents section. As you said, it will display all title-related data in one place, which is more logical.
Re: language display, we'll also have to decide what to do with titles that are not translations, but first we need to determine whether we want to move the Container line as per above. Any objections? Ahasuerus 18:08, 3 March 2018 (EST)
How about the anthologies/collections that contain more than one language? There are some in English/Spanish for example and a lot more from languages that had historically lived alongside another language (ex-Yugoslavia or ex-USSR for example) Annie 18:36, 3 March 2018 (EST)
As for "titles that are not translations": The most consistent way would be to always display the language, no matter if it's a translation or not. That way, a user does not have to make any assumptions about the language or navigate around to find out about it.
One more thing about NOVELS: my suggestion above assumed that there's only one title record in the contents section, therefore I put the language next to the title record of the novel, but this is wrong, because there can of course be other titles like a foreword ESSAY. We could either display the language for each of the titles then, which is a bit redundant, or, as a completely new and different suggestion, generally separate the language information into a "Title Language" line. See my new example below.
As for anthologies/collections that contain more than one language: the software already handles this and displays the language next to the title if its language is different from the language of the container title. See Selected Works of Edgar Allan Poe, Bilingual Edition for example. As a new feature, the software might add something like "multi-language publication" to the "Container Title" line or, more detailed, display the language of the publication's title record language plus all languages of the title records contained in the pub, e.g.:"[Englisch, French]" .
Here a two new examples which try to take the latest comments into account:
Example for a collection:

Container Title: Selected Works of Edgar Allan Poe, Bilingual Edition: English-French • collection by Edgar Allan Poe

Title Language: English (multi-language, contains also French)

Contents (view Concise Listing)

v • Introduction (Selected Works of Edgar Allan Poe) • essay by Sarah E. Holroyd
2 • The Raven • (1845) • poem by Edgar Allan Poe
3 • Le Corbeau [French] • (1857) • poem by Edgar Allan Poe (trans. of The Raven 1845)

Example for a novel:

Title Language: English

Contents (view Concise Listing)

v • Foreword (Childhood's End) • (1990) • essay by Arthur C. Clarke
1 • Childhood's End • (1953) • novel by Arthur C. Clarke

Jens Hitspacebar 04:24, 4 March 2018 (EST)
Interesting points, thanks for thinking them through. There are a lot of possible permutations, so we'll have to be careful not to make the Contents section too busy. I think it would be best to do it one step at a time, starting with moving the Container line down as suggested above. Ahasuerus 00:11, 5 March 2018 (EST)

Login Problem

I can' login ; I get message "Wrong user" and I suppose this come from my user name "Hervé le vieux" (with accent on "e") How can I change it ? If not, can I create a new user

Thanks for your help —The preceding unsigned comment was added by Hervé le vieux (talkcontribs) .

Since you are able to post on the Wiki side, I assume that you are having trouble signing on on the database side. I just tried creating a new user name, "Hervé le vieux", on the development server and it seems to be working fine. Could you please post the exact message that you are seeing? Does it say "Login failed: Bad password" or something else? Ahasuerus 10:25, 8 March 2018 (EST)

Publication page: changes to the Container Title line

As per this discussion, the "Container Title" line has been moved to the Contents section. While working on this change, I identified and fixed the following display bugs:

  • under certain circumstances the "Contents" line would be displayed even if there were no titles to display
  • NOVEL publications which contain essays written in a different language wouldn't display the essays' language in the Contents section

Let's give it a day or two to make sure that the changes look good and that no new bugs were introduced. Once the dust settles, we can start implementing the other changes proposed by Jens. Ahasuerus 15:41, 12 March 2018 (EDT)

P.S. Depending on your browser settings, you may need to do a full Web page reload (usually Control-F5) for the new Container Title line to display correctly. Ahasuerus 15:43, 12 March 2018 (EDT)

I like this change, it is a clear and logical way of displaying the information. But, the expression "container title" is confusing to neophytes. Maybe call it "Anthology title," "Collection title," or "Chapbook title" according to type? --Vasha 18:26, 12 March 2018 (EDT)
Sure, we can do that if there are no objections. Ahasuerus 10:41, 13 March 2018 (EDT)
Done. Ahasuerus 13:44, 15 March 2018 (EDT)
Looks good. But "Editor Title" should be "Magazine Title" for clarity. --Vasha 14:35, 15 March 2018 (EDT)
The catch with EDITOR titles is that they are used by both Magazine publications and Fanzine publications. Is there a term that would cover both magazines and fanzines? Perhaps "Periodical" or something similar? Ahasuerus 14:44, 15 March 2018 (EDT)
Why not just say "Magazine/Fanzine"? Periodical is just as bad as EDITOR in this context (especially for people with weak English) Annie 14:49, 15 March 2018 (EDT)
After thinking about it for a few minutes, I wonder if trying to hide/obfuscate the fact that our container title type for magazines and fanzines is EDITOR will work. After all, we display EDITOR on other linked pages, so a discrepancy is likely to create confusion. For example, take the first issue of Unknown. It says "Editor title: Unknown - 1940" which then takes you to the title page. As long as the Title Type line says "EDITOR", displaying anything else on linked pages may create more ambiguity than clarity. Ahasuerus 15:13, 15 March 2018 (EDT)
How about "EDITOR (Magazine/Fanzine) Title". This way it is not confusing for editors and at the same time someone coming from outside won't wonder what EDITOR is and why it is not a human name. :) Annie 15:22, 15 March 2018 (EDT)
That may work. Ahasuerus 15:56, 15 March 2018 (EDT)
Sorry for being a bit late: the change looks good, I like it. But one thing about prefixing the "Title" with "Editor", "Anthology" and so on: The same information is already printed redundantly in the same line before the author is printed. Why not just omit the prefix? Like this: "Title: Selected Works of Edgar Allan Poe, Bilingual Edition: English-French • collection by Edgar Allan Poe". There's "collection" printed before the author. Isn't that sufficient? But it's also perfectly ok to leave it as it is now :) Jens Hitspacebar
The thing about "container" titles is that they are not quite like the titles in the Contents section, which is why they appear on a separate line. For example, they can't have pages associated with them. In the past we have variously referred to them as "main titles", "reference titles", "container titles" and "referral titles". I think it's useful to try to convey this difference to our users, we just need to find a more elegant way to do it. Ahasuerus 13:30, 16 March 2018 (EDT)

ISBN-less e-pubs without an ASIN - changes

The cleanup report "ISBN-less e-pubs without an ASIN" has been modified to ignore Project Gutenberg publications. As of this morning, there are 2136 outstanding pubs. Some of them were never sold by Amazon and will need to be ignored by a moderator. Many others, however, were created based on Amazon records, notably Amazon DE, so we will want to add their ASINs. Ahasuerus 16:45, 12 March 2018 (EDT)

Ken Kelly vs Ken W. Kelly

I had been looking at the 97 pieces of interior art that someone added and did not properly variant in Ken Kelly's page. Looking at where they need to go (Ken W. Kelly), it feels like we just need to reverse this pseudonym and make Ken Kelly the canonical. Is there someone working on this at the moment and anyone opposing me just going and fixing the canonical author here? Annie 14:57, 13 March 2018 (EDT)

That may be my bad. They are all art cards from the same pack. The pack wasn't varianted, but the individual images are sometimes matched up to existing covers. I was going to figure out what got varianted as I matched covers. I don't think this one set would be reason to change the canonical entry. Doug H 22:44, 13 March 2018 (EDT)
It is not just because of it - if you look at the author, most are missing the W. and are varianted Annie 23:27, 13 March 2018 (EDT)
I definitely prefer "Ken Kelly" as the canonical name. I entered both of the books of Kelly's art, and the initial isn't used, even in his signature in the one signed book. I suppose the argument for including the "W" is that his signature is usually "KWK" with the "K"s represented by "C"s with a vertical line through them and followed by some scribbles that could charitably be "elly". But I haven't seen "Ken W. Kelly" used. I suggest that "Ken Kelly" is fine, and probably "K.W. Kelly" would be acceptable, but that "Ken W. Kelly" is a poor choice. Bob 20:07, 14 March 2018 (EDT)
The numbers agree with you (I did not do any counts before I posted yesterday - I was just going by the look of the page) - 204 entries on the W page carry "only as by Ken Kelly" line and 140 "as by Ken Kelly" and we have 540 records (variants and main ones) altogether on the page (the other 3 pseudonyms have less than 25 altogether). And a lot of those 540 will disappear in the switch (as we won't need a parent)... Add the 97 coming from the no-W page and even if half of them get merged somewhere, we still have the Ken Kelly majority growing. The numbers may be a bit off but not by much.
Unless someone disagrees, I will deal with this whole thing over the weekend and into next week (notifications and so on) and switch the canonical. Annie 20:25, 14 March 2018 (EDT)
And done. Phew. Next time I decide to reverse the canonical name of another artist, please someone smack me at the back of my head... :) All should be in order now but if your Ken Kelly books are handy, you may want to do one more check just in case. Annie 00:44, 11 April 2018 (EDT)

Secondary Verification Sources - Bleiler's Science-Fiction: The Early Years

I see that two of Everett Bleiler's reference works are listed as sources for secondary verification. But not his 1990 reference book Science-Fiction: The Early Years. I was wondering why not? I do see that it is used as a source of Reviews for the titles he discusses, and is referenced in Notes. PatConolly 02:52, 15 March 2018 (EDT)

I don't have this Bleiler, but it appears to be a good source. From the technical perspective, it would be easy to add. Ahasuerus 14:09, 15 March 2018 (EDT)
I have this one somewhere in the still unopened boxes - I would support adding it (I may even try to find it and do some verifications based on it) Annie 14:42, 15 March 2018 (EDT)
Cross-checking the list of reviews in our verified publication against what Google Books shows me, I see that many reviews cover short fiction. Typically, they do not provide detailed bibliographic information, so they are not very useful as secondary verification sources. However, some reviews cover novels and provide enough bibliographic data to create secondary verifications. On balance, it looks like it would be a worthwhile addition. Ahasuerus 13:15, 17 March 2018 (EDT)
The entries are quite similar to Science-Fiction: The Gernsback Years which we already include. If we do add it, we should probably also add Bleiler's The Guide to Supernatural Fiction which is uniform with his two other volumes from Kent State University Press and is perhaps more book oriented rather than story oriented. --Ron ~ RtraceTalk 15:56, 17 March 2018 (EDT)
Makes sense. Also, it occurs to me that the more secondary verification sources we have, the more screen real estate they occupy on publication pages. At some point we may have to redesign the secondary verification section of the Publication page. Ahasuerus 17:24, 17 March 2018 (EDT)
Perhaps make it another "view" like the "Awards", "Alphabetical", and "Chronological" views we currently have for people? ···日本穣 · 投稿 · Talk to Nihonjoe 20:36, 22 March 2018 (EDT)
If there are no objections, I will add The Guide to Supernatural Fiction and Science-Fiction: The Early Years early next week. Ahasuerus 14:27, 18 March 2018 (EDT)
Done. Supporting Wiki pages to be added shortly. Ahasuerus 15:33, 21 March 2018 (EDT)

(the discussion of the proposed secondary verification redesign has been moved to a new section since it has become a separate topic)

Marian O'Hearn

The discussion of container titles (see above) led me to this pulp author earlier today. Marian O'Hearn sold 3 novellas/short novels to Unknown in 1939-1941, but most of her output was non-genre (westerns, noir, romance, etc.) There is some confusion re: her legal name and her relationship with "Anita Allen" who may or may not be a pseudonym. Of course, the Anita Allen who has been active as a writer, artist and editor since the mid-1990s is a different person.

Would anyone happen to know more about this author? Ahasuerus 13:05, 16 March 2018 (EDT)

Language to add: Asturian

Query for anyone who knows about the languages of Spain: being as there are speculative works written in the Asturian language, it is going to be added; the only question is how to refer to it. Wikipedia says that it used to be called "Bable;" is this term still in use at all? The article in the Asturian-language Wikipedia says that Bable refers to only one of the local variants of Asturian. --Vasha 00:29, 17 March 2018 (EDT)

ISO 639-2, the standard that we use for language coding, says that the code "ast" stands for "Asturian; Bable; Leonese; Asturleonese". The Library of Congress coding guidelines, which are based on the same standard, say "Asturian - use Bable". Perhaps we could use something like "Asturian/Babel". Ahasuerus 00:48, 17 March 2018 (EDT)
Considering that we are dealing with bibliographical data and in some cases relatively old sources, I would vote for the double name - this way someone finding an old article in a magazine that allows them to catalog a few more books will have a better chance to find the language in the list. Annie 03:17, 17 March 2018 (EDT)
Yeah, I guess we should go with "Asturian/Bable" for the sake of anyone who's getting data from the Library of Congress or old sources. --Vasha 17:48, 17 March 2018 (EDT)
I think "Asturian/Bable" covers most of the cases, as fine dialectal distinctions are unnecessary here. We can always correct this later, in the unlikely case some related problem arises. This being said, "Asturian" would be good enough for me, but I suppose "Asturian/Bable" would prevent any undue soul-wrenching questioning from puzzled editors. Linguist 05:49, 18 March 2018 (EDT).
Thanks, folks, I plan to add "Asturian/Bable" later today. Ahasuerus 12:56, 18 March 2018 (EDT)
Done. Ahasuerus 14:05, 18 March 2018 (EDT)
Thanks. Google books has a partial preview of Historia de la lliteratura asturiana; apparently it mentions "literatura fantástica" on quite a few pages, but I couldn't get enough of a look at it to find any specific titles except for two by Adolfo Camilo Díaz and one by Xandru Fernández, which I've added. --Vasha 14:58, 18 March 2018 (EDT)

ISFDB downtime - 2018-03-18

The ISFDB server will be unavailable between 2pm and approximately 2:10pm server (US Eastern Daylight) time. I will be purging old versions of Wiki pages and adding support for the Asturian/Bable language. Ahasuerus 13:30, 18 March 2018 (EDT)

We are back up. Ahasuerus 14:05, 18 March 2018 (EDT)

Publications monitoring

The only way to monitor a publication for changes is to verify it. However, if you are working on a specific language, series or authors, you may want to monitor changes even in the books you cannot technically verify. One option is to Transient verify it but I think that this is stretching the definition too much - either you have the complete book on your e-device or on your desk or it does not count. So how about adding a third verification/monitoring option that triggers the "publication changed" functionality but without being treated as a verification in any other way (adding a green checkmark in the verified column in lists or requiring a notification for bigger changes). Thoughts? Any good reason not to have it? Annie 21:53, 18 March 2018 (EDT)

If I am reading the proposal correctly, you'd like to be able to create editor-specific "publication watchlists" similar to the way editors can put Wiki pages on their watchlists. Is that about right? Ahasuerus 23:43, 18 March 2018 (EDT)
Yep - but because the DB does not have comparison between versions the way wiki does, it can use the same mechanism that we have for seeing the Primary verifications changes (the My Recently Changed Primary Verifications page) - either on the same page or via a different page. Annie 23:55, 18 March 2018 (EDT)
Noone else interested? :( Can we at least file it as an FR? Annie 18:17, 29 March 2018 (EDT)
I would like this feature, as well. Maybe have it create a "watchlist" similar to the wiki, accessible through a link such as "My Watchlist" in the "Logged in as" menu section in the db. If it operated similar to the "My Changed Primary Verifications", it could even have a "new" indicator when something on it changed. Perhaps these two lists could be combined into one, so it showed both PV and watched items in the same list. ···日本穣 · 投稿 · Talk to Nihonjoe 18:41, 29 March 2018 (EDT)
OK, FR 1136 has been created. It will require some thought and design work, especially the functionality mentioned by Nihonjoe. Ahasuerus 19:41, 29 March 2018 (EDT)
Why not treat is a new type of "primary" verification but without showing a green checkbox next to the book in a listing? That will get the My Changed Verifications covered automatically, the logic for multiples is there (I do not mind people knowing what I am monitoring... plus this way an editor will know who they can ask questions about that publication) and just the green marks need to be taken care of. I am oversimplifying I know - but just a thought. Annie 19:47, 29 March 2018 (EDT)
I can think of a few different ways to implement this functionality. For example, we could re-implement the current primary verifier notification system by moving all primary-verified pubs to their respective primary verifiers' watch lists. Ahasuerus 20:31, 29 March 2018 (EDT)
It would indeed be theoretically nice to get notifications of changes to things I've worked on. But I feel like without comparison of versions it has somewhat limited usefulness and not high priority. --Vasha 20:33, 29 March 2018 (EDT)
I agree that the ability to compare versions is a higher priority. It's number 3 on my list of "significant changes" at the moment. Ahasuerus 21:36, 29 March 2018 (EDT)

nonfiction vs. non-fiction

I just noticed that there is a category called "Nonfiction" on summary pages for titles that have the publication type written "non-fiction." Shouldn't we settle on just one form? (I would prefer it without the hyphen, personally.) --Vasha 22:49, 19 March 2018 (EDT)

That's a good point. Either way works for me, although "nonfiction" may be slightly better. Ahasuerus 00:01, 20 March 2018 (EDT)
I like the non-hyphenated one as well. Annie 19:21, 21 March 2018 (EDT)
OK, "non-fiction" has been changed to "nonfiction" on Publication pages. Ahasuerus 21:53, 21 March 2018 (EDT)
What about in the table display on title pages, where the "Type" column has "non-fic"? --Vasha 22:56, 21 March 2018 (EDT)
Oh, I see. Hm, we can change it to "nonfiction" as well, but that table's columns are already narrow, so it will cause wrapping at most resolutions. That's why we use abbreviations like "coll", "anth", "mag", etc. We could use "nonfic", but it would look kind of awkward. Ahasuerus 23:34, 21 March 2018 (EDT)
Yeah, "non-fic" broken into 2 lines looks fine in the table. --Vasha 11:30, 22 March 2018 (EDT)
How about "nf"? ···日本穣 · 投稿 · Talk to Nihonjoe 14:49, 22 March 2018 (EDT)
I am not sure "nf" would be intuitive to casual users. Ahasuerus 18:48, 22 March 2018 (EDT)
Maybe "nfic"? Since its an abbreviation, I think "nonfic" would be fine, too. ···日本穣 · 投稿 · Talk to Nihonjoe 20:38, 22 March 2018 (EDT)
Or perhaps just "non"? ···日本穣 · 投稿 · Talk to Nihonjoe 20:39, 22 March 2018 (EDT)
Nah. Being as "non-fic" breaks onto two lines, the hyphen looks natural, and it's clearer than any of the other suggestions. --Vasha 20:56, 22 March 2018 (EDT)
Why does it need to be two lines? "non-" is only slightly shorter than "nonfic", so it's really not saving that much space. ···日本穣 · 投稿 · Talk to Nihonjoe 20:58, 22 March 2018 (EDT)

Issues with the display of re-issued titles where a second author is added

The Gateway ebook reissues of Lionel Fanthorpe's Badger novels are complicated by the fact that they are now credited to "Lionel Fanthorpe and Patricia Fanthorpe", however many of the entries we have for these ebooks are credited to "R. L. Fanthorpe" only (his canonical name), eg. Space-Borne. I've been trying and failing to get entries to display correctly on both Lionel and Patricia's pages by using "Lionel Fanthorpe" and "Patricia Fanthorpe" as authors, as stated on the ebooks' title pages.

Using "Add a Variant Title or Pseudonymous Work to This Title" allows me to add Patricia Fanthorpe, however the title then does not show up on her page.

Adding an entirely new publication with authors "Lionel Fanthorpe" and "Patricia Fanthorpe" then varianting "Lionel Fanthorpe" to "R.L. Fanthorpe", again the title does not show up on Patricia Fanthorpe's page.

Those that do appear on Patricia Fanthorpe's page are credited to either "R. L. Fanthorpe" only (eg. The Triple Man) or directly to one of Fanthorpe's pseudonyms (eg. "writing as Lee Barton", The Shadow Man), neither of which is a correct display. PeteYoung 03:18, 20 March 2018 (EDT)

Could you please clarify why you think that they are displayed incorrectly? If Patricia Fanthorpe was a co-author of these books, then we need to add her to the canonical titles and create variants as needed, which is what has been done here. Ahasuerus 08:29, 20 March 2018 (EDT)

I have left up a test publication of Space-Borne as an example of this display problem.

I don't recall this being previously discussed so I'm wondering if anyone knows of a work-around to get things to show correctly on both authors' pages, or if this is a software limitation issue. If so, we should perhaps at least add a Note to each ebook title explaining this.

TIA. PeteYoung 03:18, 20 March 2018 (EDT)

If you have a title credited to Author1 and Author2 and variant it to a parent credited to only Author1 (which is the case in your example pub), then you are starting that the title was actually only written by Author1 and the Author2 credit (while it may have been in the publication) is not correct. In such cases, it will only appear on Author1's summary page. On the other hand, if you have a title credited to Author1 and variant it to a parent credited to Author1 and Author2, then you are stating the title was actually written by both authors and the single credit (while it may have been the only one in the publication) is not correct. In such cases. it will appear on both authors' summary pages. Based on your example, this appears to be the second case (the original publication was credited to only R. L. Fanthorpe, but in reality Patricia Fanthorpe contributed to it) and you have the varianting backwards. -- JLaTondre (talk) 16:40, 20 March 2018 (EDT)
Thanks Ahasuerus and JLaTondre, this clarifies things. Adding PF to the canonical title seems counter-intuitive at first because her author credit only came later, but at least it does display properly now. I will eventually go through all Fanthorpe's titles as I see quite a few of the ebooks have been entered incorrectly in all sorts of permutations – variants of variants, or as by the original pseudonym or the canonical name, etc. Thanks again. PeteYoung 22:25, 20 March 2018 (EDT)

The Tangled Lands

In February, Paolo Bacigalupi & Tobias Buckell published 'The Tangled Lands' http://www.isfdb.org/cgi-bin/title.cgi?2300852, which contains 4 novellas (2 reprint, 2 new) set in a shared world. The publisher, Saga, calls it a 'novel', but I originally entered the book in ISFDB as an anthology. Vasha suggested, instead, it should be a collection. I checked with Locus and the authors, and they agreed with Vasha. Markwood 20:36, 29 March 2018 (EDT) Here is the full response from Carolyn Cushman, 'Books Received Editor' for Locus:

"As it happens, I was brooding over this one myself. Anthology does seem like the technically correct designation, but it doesn't feel right. Liza and I debated the three options, asked the authors (who were a little up in the air themselves, but didn't really think it was a novel) and finally decided to go with collection, as in "collaborative shared-world collection." Hope this helps."

Secondary verifications - proposed redesign

(moved from the Bleiler discussion above)

Since the additions are brand new, would this be the best time to group the Bleilers together before everyone gets used to them split up like this? I just think it looks a little odd to have OCLC sandwiched like it is now. caught myself clicking the wrong line a half-dozen times already [very old dogs/new tricks kind of thing ....]. Just a thought. --~ Bill, Bluesman 18:41, 22 March 2018 (EDT)

We can certainly do it, but if we are going to rearrange some of them, we might as well take a look at the big picture. How about we order all secondary verification sources alphabetically? Ahasuerus 18:50, 22 March 2018 (EDT)
Sort of there already: Clutes grouped, Reginalds grouped; if the Bleilers get grouped it doesn't leave much anyway, so why not? I would make what may seem like an odd request. If the look is getting upgraded could the actual verification 'dots/clickable areas' be changed from the wee circles to the elliptical ones that are present nearly everywhere else? I ask because there are times when I can click on the wee circles half a dozen times and they just don't 'react' [other than to flash briefly]. I never have that happen with the elliptical ones. I'm sure it's just a browser 'thing' but it doesn't make it any less frustrating. Another thought on a possible new look, alphabetical but in sections, so that Locus would have three: Contento [could finally drop the [1]]; Locus Index [again drop the 1] and Miller/Contento; a main heading of Bleiler would then have four sub-sections: Early Years, Gernsback, 78 and Supernatural. And so on. Would look good and be less repetitive. --~ Bill, Bluesman 19:35, 22 March 2018 (EDT)
I support both proposals - these small dots are hell when I work from a touchscreen (the phone and the small Fire - it may be because of the size and not because of the touchscreen but...) and grouping them together makes a lot of sense. Annie 19:41, 22 March 2018 (EDT)

(unindent) Let me make sure that I understand the comments re: the verification buttons. Do they look different compared to the buttons used by other Web pages (Author Merge, Title Merge, Publisher Merge, etc)? Either way, I can certainly make them larger.

Re: reordering secondary verification sources, keep in mind that the three sources currently hosted by Locus are not guaranteed to stay there. For example, Contento used to have his own site.

Here is what a strictly alphabetical sorting would yield -- note the changes to the spelling:

  • Bleiler 1978
  • Bleiler Early Years
  • Bleiler Gernsback
  • Bleiler Supernatural
  • Clute/Grant
  • Clute/Nicholls
  • Contento (anth/coll)
  • Currey
  • Locus Index
  • Miller/Contento
  • OCLC/Worldcat
  • Reginald1
  • Reginald3
  • Tuck

Here is what it would look like with the grouping that Bill proposed:

  • Locus
    • Contento (anth/coll)
    • Locus Index
    • Miller/Contento
  • Bleiler
    • Bleiler 1978
    • Bleiler Early Years
    • Bleiler Gernsback
    • Bleiler Supernatural
  • Clute
    • Clute/Grant
    • Clute/Nicholls
  • Reginald
    • Reginald1
    • Reginald3
  • Currey
  • OCLC/Worldcat
  • Tuck

Ahasuerus 18:35, 23 March 2018 (EDT)

Actually I was still for alphabetical, but grouped within that. After looking at both the grouping works the best. I can see where the three under Locus may change as the Miller/Contento is now wholly subsumed within Galactic Central and is available online. It's the only one besides OCLC that is a 'current' database, though our definition of what it constitutes should perhaps be revisited in light of it no longer being solely limited to the CD-ROM Locus used to sell [they don't even offer it anymore]. The Locus Index is virtually 'dead', with Bill Contento retired from the magazine he's doing nearly 100% magazines these days, and doesn't even have 'write' access to the Index [at least the last time I contacted him; he still keeps track of changes people send in but has no idea if they'll ever be implemented]. It doesn't appear that anyone there is likely to continue the online releases [it's been ten years since the last one]. When I think about it, we have kind of cornered ourselves [past the truest verification process which is book-in-hand] as there is only OCLC on our list which is 'current' [and they suck at so many levels, you'd think Librarians would know better - it's a mixed blessing that they are now citing us as a source yet managing to mis-cite at the same time]. I can see Galactic Central becoming a part of the list as they're still going strong [with both Bill Contento and Phil Stephenson-Payne, they've got credentials] though for how long who knows, and they are self-limiting to magazines/short-fiction [anthologies/collections]. Phil has already said he's 99% sure his author bibliographies will never see any more updates. As for the 'buttons', for me there is a major difference between the way they react depending on the shape and size. If you are in a merge window, the choices are all squares. I can touch any portion of a square with the cursor and it reacts [I use the 'arrow' type]. The active button below the options, an elongated ellipsoid shape again reacts no matter where the cursor touches it. In the Verification window the buttons are circles and if I don't touch them absolutely dead-center they will 'flash' but NOT react/change. Drives me nuts. I'm probably the only one here who bothers to 'set' the N/A's for verifications which can be up to thirteen [now fifteen] for any given record so it's not a trivial thing if I have to hit each one 2-6 times before it will react. Some days are better than others [or my aim is .....]. --~ Bill, Bluesman 20:48, 23 March 2018 (EDT)
For me - they do not look smaller when I look at them alongside the ones into the "select what to keep in a merge" screen but because there are so many of them in such a small place (the spacing vertically is especially cramped), I think I am just clicking slightly off on an attempt not to catch the one under/above it so I end up clicking between them. They feel smaller even if they are not. I wonder if spacing them a bit further from each other won't be enough to solve this... Bill may be having other issues with them :)
And I like that second "grouped" view a lot more than the alphabetical one... I would argue that we should put OCLC at the top though (it is the most common one after all) Annie 18:43, 23 March 2018 (EDT)
OK, I have created an FR for secondary verification buttons.
Would anyone else have an opinion re: grouping secondary verification sources? Ahasuerus 08:49, 27 March 2018 (EDT)
An FR has been created. Ahasuerus 20:25, 28 March 2018 (EDT)
Strictly alphabetical sorting is the first choice.--Wolfram.winkler 01:32, 20 April 2018 (EDT)
I am sort of partial to organizing these by original publication data much as we already do with titles and publications in the rest of the database. Uzume 15:05, 9 June 2018 (EDT)

Premio Ignotus changes

Please note that, based on the information in this PDF document, Premio Ignotus has been changed to a "poll". Ahasuerus 11:50, 25 March 2018 (EDT)

External Identifier search enhancement

Please note that the External Identifier search logic has been enhanced to support our standard wildcards (% and *). Ahasuerus 11:07, 26 March 2018 (EDT)

"My Recently Changed Primary Verifications" changes

"My Recently Changed Primary Verifications" has been changed to display "External ID" in the "Changed Fields" column. Ahasuerus 10:33, 28 March 2018 (EDT)

opinions? choosing translations to link reviews

Hi everyone, what do you do when you're entering a review of a translated work, and it's not clear which of several alternative translations the reviewer is working from? Do you create review records linked to all the possible alternatives, or what? --Vasha 08:43, 29 March 2018 (EDT)

Do you have an example? I don't completely understand your question. ···日本穣 · 投稿 · Talk to Nihonjoe 13:28, 29 March 2018 (EDT)
Asimov's Foundation had been translated at least twice into Spanish (let's say in 1975 and in 1980, from different translator) If there is a review in a magazine in 1999 that you have no access to (adding based on secondary sources), which of the two variants do you link to? It is rarely a problem when linking with the magazine at hand - reviews tend to be for editions or there is enough in the review to tell you which one it is about) but with secondary sources... Annie 13:50, 29 March 2018 (EDT)
Exactly. I am working from secondary reports of reviews published in Spain in 2000, and We (Nosotros) by Yevgeny Zamyatin had three translations in print in Spain between 1992 and 2000 (a bunch more before that). What should I link the review record to, then? --Vasha 13:59, 29 March 2018 (EDT)
That's one of those cases where I wish we could have variants of variants - so we have a "Spanish" main variant that we can use in such cases and which will show the list of the Spanish reviews regardless of the translation.
As the things stand, I would make best guess and pick one of the translations and add a note in the rest (and in it) explaining the situation. Plus a note in the publication (the magazine/book) for the verifier, when there is one, to check the links and adjust. Not much more that we can do. Going to the original loses information (the fact that it is a Spanish review that is reviewed). Annie 14:11, 29 March 2018 (EDT)
I like this idea (having a main variant for each translated language), though it would require adjusting the database software to allow variants of variants (meaning Spanish translations 1 and 2 would be variants of the Spanish main variant, which in turn is a variant of the original English work). ···日本穣 · 投稿 · Talk to Nihonjoe 14:36, 29 March 2018 (EDT)
Adding support for "variants of variants" would require a fundamental redesign of the way the software works, probably hundreds of man-hours, so I expect that it wouldn't be feasible. Ahasuerus 00:07, 30 March 2018 (EDT)
Guessed as much - not all wish items are bound to happen :) Annie 00:15, 30 March 2018 (EDT)
How about this for a note in the publication notes:
The review record for each work reviewed in this publication has been linked to a Spanish translation. If more than one translation existed, one that that was likely to be available to the reviewers was chosen. Here are the works with multiple translations, with the linked one highlighted:
  • Fundación (Foundation): Pilar Giralt Gorina (1976); also trans. by M. Blanco (1975); Antonio Ribero Jordá (1965); Mariano Orta & Rafael Orta (1961); uncredited (1955).
Etcetera. And then: "Note to verifiers: Please attempt to determine which translation the reviewer is referring to." This is all too much work, but it's the only way to enter the contents of the book at present. --Vasha 14:42, 29 March 2018 (EDT)
Use the {{BREAK}} template to send the details on a separate page (so the record itself is not too heavy (and leave the first paragraph only on the main page)? (Templated described here if you had never used it. Especially for this one that may have a very long list... :) Annie 14:49, 29 March 2018 (EDT)

J. Gregory Keyes canonical name change

Anyone opposing the change of the canonical name for J. Gregory Keyes to the much more recognizable and used name of Greg Keyes? If not objections in the next few days, I will proceed with the change late next week. Annie 23:20, 31 March 2018 (EDT)

Do it.--Wolfram.winkler 07:39, 18 April 2018 (EDT)
I Agree that "Greg Keyes" should be his canonical name. Ahasuerus 10:27, 19 April 2018 (EDT)
Nothing happens.--Wolfram.winkler 07:27, 29 May 2018 (EDT)
Too many projects, too little time :) Mr. Keyes has a new canonical name now. Annie 13:53, 29 May 2018 (EDT)

The paperback formats again

I had been going through all the Bulgarian books we have (fixing what needs fixing and taking a note of what we have so that I can then add the rest) and had been thinking about formats again. The ISFDB standards had always been very US-centric (which works for some other languages, does not work very well for some). I have no issues with that - the pb/tp separation makes sense in its form considering the history of the genre. But... that ends up with almost everything in other languages to "tp". Which makes the "but it is paperback, why would I call it trade paperback" talk happen too often. What we call paperback is a mass market paperback. So why don't we just call it so, rename pb to mmp, rename the good old "tp" to paperback and be done with it?

Alternatively - add a single new format called softcover (and eventually a new field for "exact size" (exact being the expected, not the one based on the cutting - while cutting can produce slightly different sized books, most of them are supposed to be a specific size) and stop trying to fit the square blocks into the very round holes (what got me thinking is the small Bulgarian format which is .5 cm too wide to fit into pb (it is 70×100/32 which makes it 16.5/12.0cm - the few we have in the DB needs resetting to tp and it gave me a pause again).

And in case someone had ever been interested in what those weird formats of Eastern European books mean, here is a handy table (in Russian, sorry).

PS: And happy Easter for the ones that celebrate today. Annie 16:28, 1 April 2018 (EDT)

Yes, the US is different from everyone. It's fine that this database started out with the ambition of cataloguing only English-language publications; and internationalization has mostly worked out well, but this may be the worst internationalization issue remaining. Most publishing markets do make a distinction between "pocket" paperbacks and larger, higher-priced paperbacks; the question is how to record that distinction without getting bogged down in the details of the myriad ways that that distinction is implemented in practice. (By the way, Spanish publishers have a format called "bolsillo" ("pocket") which is often 17.5 cm tall by can be less). --Vasha 16:53, 1 April 2018 (EDT)
At this point, I had started to add the format to all the non-English records I am making (and I have half a mind editing all the Russian ones we have as well that do not have this information yet). But if we are going to do something about all this, sooner is better than later. Annie 17:24, 1 April 2018 (EDT)
See Rules_and_standards_discussions#Format_pb_vs._tp_-_interim_solution_for_German_publications where the most recent discussion about this is happening. Jens Hitspacebar 16:44, 9 April 2018 (EDT)
Jens, I know about that one. Pointing any attempt to look at this from a different perspective to the same old arguments is counterproductive though :) Annie 16:46, 9 April 2018 (EDT)
Sorry, Annie, I don't understand what you mean. Except for your suggestion to rename pb to mmp and tp to pb, the other thread contains, among others, the arguments you've provided above. So, what argument exactly is counterproductive? Jens Hitspacebar 16:54, 9 April 2018 (EDT)
The other thread had turned again into "what to do with the German formats". Which is understandable but it also is just moving the problem in a different place - we cannot solve this one country at a time.
And somewhere in the long German discussions (which happens for German because we have enough editors to actually have a conversation), the main points are lost - yes, the Taschenbuch needs a solution but so do similar types across the world (as I mentioned above, the Bulgarian small format is one idea bigger than a pb allows as well) and solving it piecemeal will end up in a bigger mess IMHO (do we really want a dropdown with 100+ formats?) . This thread was an attempt to restart the conversation without bringing in the exact problems of the German formats or calling it a solution for the German formats(which is why I did not link it to a thread pointing to the German formats specifically). The cleanest way just may be to stop trying, add a free text "format" field that each country can populate any way they want, add/reuse the "tp" to mean softcover that is not a mmp and be done with it. As long as the free text format field is used based on policies (per country), that will cover our cases. Annie 20:38, 9 April 2018 (EDT)
I heartily agree that we can't go changing the drop-down list every time we want to make a solution for a new country!
The idea of having a paperback free-text field is an interesting one. It would be difficult to keep the data standardized in such a field (it's a bit much to expect moderators to know what the standards are for every country that is submitted). Still, having such a field, which could be searched, would provide more data than the current state where everything is lumped into tp with very inconsistent notes in the notes field. TP and mm could be reserved for US publications only, which is,still the majority, so worthwhile having dedicated categories. We'd have to inform users that tp would contain a mixture of US and everything else for the foreseeable future. Transitioning all us mass markets to mm would be easier.
The thing is, is the extra data provided by having a free-text field worth the (considerable) trouble of creating and maintaining it? I kind of doubt that personally. But it is up to the people who would be using it the most to argue about that; I don't have much stake in the debate. --Vasha 21:39, 9 April 2018 (EDT)
That's where the help page is your best friend - it won't be much different than dealing with currencies for example or the magazines formats - every time a new one shows up (or one I had not seen lately), I go chasing information. And it will not be a mandatory field. Bulgarian and Russian books always have format printed and it describes the book perfectly for example (the ones that do not print it are breaking a rule). So having this in the DB makes sense. :) As much as I wish that this would be a problem, we just do not get that many different countries' books (yet) so it probably won't be as much of a an issue than one would think - the DB is still too US-centric to make it comfortable adding a lot of others - at times it feels like all the information I want to be able to search by ends up in the notes due to lack of fields (proper format, Translators to name a couple) :)
However - we need to think of what we already have - the tp and pb of the non-English books won't be that easy to convert and in some cases the verifiers are not around. So I would say that we will have a mix of the old standard and the new one for a very long time - but that is not a reason not to try to find a solution. Growing pains are not a reason not to grow up :) Annie 21:57, 9 April 2018 (EDT)
My answer is, yes, we really want a dropdown with 100+ formats! This is the only and perfect solution. But we need an administrator, who says: yes, we can do it. If no one makes a decision, the discussion will never ends.--Wolfram.winkler 07:36, 18 April 2018 (EDT)
Most of our decisions are made after reaching consensus. The downside of this approach to decision-making is that there are times when we can't reach consensus, so things remain hanging for a long time. The upside is that we are less likely to lock ourselves into a solution which may prove unworkable or counterproductive in the long run. I find our current approach generally superior to the alternatives which we tried in the past.
Re: formats, different bibliographers have tried different approaches. Many library catalogs and booksellers record one (or more) of the dimensions because it informs their shelving options.
My current thinking is that it may be best to take the data which we currently store in the "Format" field and split it between multiple fields. The "Format" field would keep the binding data: "paperback", "hardcover", "magazine binding", "electronic", etc. A new field (or perhaps fields) would be added for "dimensions". All "pbs" would be converted to "paperback" and the "dimensions" field would be populated accordingly as part of the conversion process.
This is very preliminary and would require fleshing out the design: do we have one field for the dimension data or two? how do we convert inches to millimeters and vice versa transparently? etc. Ahasuerus 11:58, 19 April 2018 (EDT)
A new field (set of fields) sound great - it always made more sense when you end up in an international environment. One note though - while converting the 70/100/32 (or A3 or the UK B format) is possible, I would make an argument that if someone is searching for a book based on size or wants to see size, they would use that and not the corresponding size in mms so being able to use that in a field somewhere and the standard may have changed a bit (which can lead to incorrect conversion data). Maybe 2 fields: one allowing for these "common name" formats labels and a second for the size in mms or inches (and then use the same idea as we do with isbns and show the converted value to the other one?) Annie 12:33, 19 April 2018 (EDT)

What is the meaning of "Format"? The answer: Form und Größe or form and dimensions. Following table show the possible properties of a book, which should/could be considered. Without claim of completeness and without comments.

Bindung (Binding) Material (Material) Maße (Dimensions) Einband (Cover)
      Oberfläche (Surface) Form (Format)
Gebundene Ausgabe (Binding Edition) Papier (Paper) Länge (Length) Glatt (Plain) Matt (Matt) Ohne Klappen (Without Flaps)
Hardcover (Hardcover) Pappe (Carton) Breite (Width) Geriffelt (Fluted) Glänzend (Glossy) Mit Klappen (With Flaps)
Softcover (Softcover) Kunststoff (Plastic) Dicke (Thickness) 2D (2D) Teilweise hochglänzend (Partly High Gloss) Schutzumschlag (Dust Cover)
Geklammert (Stapled) Holz (Wood) Seitendicke (Page Thickness) 3D (3D) Laminiert (Laminated) 2D (2D)
Ringbuch (Ring Binder) Kupfer (Copper)       3D (3D)
  Stein (Stone)        
Zelle 1 Zelle 2 Zelle 3 Zelle 4 Zelle 5 Zelle 6

--Wolfram.winkler 02:55, 25 April 2018 (EDT)

Keep in mind that we also use the "format" field for ebooks, CDs and audio books. It's a catch-all field which covers a number of different data elements: type of media (paper books, e-books, audio books, CDs, DVDs, etc), dimensions, and bindings. Since a bibliography is effectively a map of the book world, ideally we would have different fields to represent different elements. Ahasuerus 09:13, 26 April 2018 (EDT)

The secret life of J. D. Tyler

According to J. D. Tyler's Web site:

  • This book (Johan) has been previously published. The title and author have changed. However, this book is the launch for a new series, and subsequent books have never been published.

The original copyright date is 2007, but I have been unable to find the original title or pseudonym. Any ideas? Ahasuerus 19:47, 1 April 2018 (EDT)

I'd say that this is it. Both the description and the first pages match. And we have it :) Annie 20:27, 1 April 2018 (EDT)
Pseudonym confirmed -- thanks a lot! Ahasuerus 21:02, 1 April 2018 (EDT)

"translator unknown" template

I think it would be useful to have a template to mark all the records that are "Translator unknown or uncredited" -- that is, no translation information. (For specific anonymous translations, on the other hand, I would write a note like "{{tr|uncredited }}; this is the uncredited translation first published by Publisher in Year." Which is different than not knowing anything about the translation.)--Vasha 15:56, 2 April 2018 (EDT)

[1] {{tr|uncredited}} --Does that template operate in the database rather than here in the wiki? Is there some clerical error of another kind?
If I understand correctly, I prefer the statement "Translation data missing", or one to the same point.
Anyway, do you have in mind that we move toward distinct title records (container titles) to hold all of the publications with missing translation data? So that we move toward one title record for the 1890 translation by Pamela, one for the 1900 translation by Paul, ..., and another for the translation-data-missing publications? [all that for publications that match particular versions of the names of the author and the work]
[2] It seems to me that translation data --including "missing" as one value and "no one has yet given this record such attention" as another value, the latter presumably null/empty/default/blank-- should be handled in a new field or two, for both titles and publications.
Pretend for a moment that we have only novels and single-work chapbooks rather than more complex content by the primary author! ;-) If what data we have, or its lack, were available in the translation field(s) of both title records and publication records, then it would be possible to display in the Publications table for a title (as we know use "" for primary verification in the Verif column) whether or not the translation data for the publication match those for the title. Probably there should be more than two values ("" and null). But two values will be adequate, for any title whose translation data is complete rather than missing, to show at a glance something very important about the integrity of the publication record--and thus about the integrity of the title itself, as I understand it.
--Pwendt|talk 16:55, 6 April 2018 (EDT)
It is more complicated than just throwing a few fields in the records though - we will want the authors that are also translators to be linked somehow as well for example... And then you have canonical name issues (if a translator works in multiple languages or you have a language that uses two different alphabets, same name is written differently but you want to know that they are the same and so on. And then when you get on the collection and anthology levels, it gets... complicated :) Annie 17:20, 6 April 2018 (EDT)
In the case of titles where someone has given attention to sorting out different translations into different title records (which is very few of them, alas) there is indeed a separate record that combines all the publications with missing data--this one for example. The thing is that we haven't implemented any real solution for how to credit translators yet. The {{tr|}} template is just a temporary measure to make translator info easier to find, which will help with transitioning to whatever we eventually transition to. I thought it might be useful to have another temporary template to make the unknowns easier to find. --Vasha 18:22, 6 April 2018 (EDT)
Well, an agreed upon wording will also do the trick. But I would not object a pair of templates: Translator_unknown and Translator_no_info. Or we can use Tr|uncredited (for the case where we have the book and it does not specify the translator) and Tr|unknown for the case where the translator may be known but the sources does not specify or whoever entered did not bother to. Annie 18:41, 6 April 2018 (EDT)
What would you suggest for the case where someone has gone through and compared the uncredited translations and sorted them out: noticed, for example, that there are two different translations that were never signed, and has created separate records for them? That is a "known unknown" you might say, a translation that can be identified by its description if not by a name. I don't want to lump those in with cases where the only thing we know about the translation is that it is uncredited. So we have three categories: unsigned-but-described, unsigned in general, and ones where no information about them has been put into the database. In the past, people didn't bother distinguishing between those last two categories; that's why the standard wording is "Translator unknown or uncredited." --Vasha 18:56, 6 April 2018 (EDT)
We cannot cover all cases - so use the templates to say unknown (thus making it found-able down the road) and then write a note after that explaining the case. Most of the "comparable" ones will be credited somewhere as well (or will be known as "the first Spanish translation", the Bard translation and so on... There is no way to create a perfect system and even with the Tr, we will have manual actions anyway - so I treat that as a prep work more than making it absolutely automated when it comes to that... Annie 19:07, 6 April 2018 (EDT)
Yes, it would work to use Tr|uncredited with additional notes to describe whih uncredited translation it is; and if it hasn't been worked on yet, leave it blank. I guess I am worrying unncessarily. --Vasha 19:25, 6 April 2018 (EDT)

ISBN warning changed

The way ISBNs are checked on submission review pages has been adjusted. Changing an ISBN-10 to its ISBN-13 form (or vice versa) should no longer result in a bogus "This ISBN is already on file" warning message. If you see anything odd, please post your findings here. Ahasuerus 17:49, 4 April 2018 (EDT)

Middle French added

Middle French has been added to the list of supported languages. Ahasuerus 10:10, 5 April 2018 (EDT)

SFBC again

What do we do we books like this one? The catalog ID in that note is not the same as a SFBC ID, correct? So it does not go in the Catalog Id? Can someone that understand these books confirm? Annie 16:40, 5 April 2018 (EDT) PS: this one has both and if there is no typo, they are not the same. So I am a bit confused here - is it a single number (and this one is just a typo) or do we have two different numbers for these books? Thanks! Annie 18:16, 5 April 2018 (EDT)

Trying this again. In this publication, which of the two numbers go into the catalog ID? I would think 1206501. If a work has only one number in the notes and it looks like the 18-0022 one here, does it get moved or do we leave this one alone? Annie 13:39, 13 April 2018 (EDT)

Fuzzy dating

This discussion has been transferred from here, so that any useful comments could be added.

Hello again ! I'm sure the subject has already been raised by some editors, but I can't find any mention of it at the moment : would there be a way for the system to accept (or to be made to accept) an approximate date, say something like 14..-00-00 to indicate "15th century" or 142.-00-00 to indicate 1420-1429 for instance ? This would allow to make the difference between the complete lack of a publication date for a work (e. g. The Odyssey) and an approximate datation for a text known for certain to have been written in a specific century or decade ? This could also be used, of course, in biographic data. This is a problem I have met quite a few times, and so have others, I suppose. There is probably a technical reason why it can't be done, but I can see no harm in asking and learning… :o) Linguist 11:22, 5 April 2018 (EDT).

Dates are a HUGE can of worms in the IT world! Each programming language and each database handles them somewhat differently. The database that we use, MySQL, officially supports dates between 1000 AD and 9999 AD, but it will grudgingly accept values in the 0001-0999 AD range (which we take advantage of.) It does not accept dates prior to 0001 -- see FR 46 -- and it doesn't accept fuzzy dates.
Having said that, there is a way to support fuzzy dates. We don't necessarily have to rely on the database to store dates as "MySQL-compliant" dates. We could change all date fields from the "MySQL date" type to the "arbitrary string of characters" type. We would then have to handle all date operations (e.g. determining which date was earlier during Title Merge operations) in our software, which we have full control over. However, there would be significant costs associated with this approach. First, all databases are optimized to handle dates quickly. If we were to move date handling to our software, many operations involving dates would slow down. Second, it would take dozens and dozens -- probably hundreds -- of man-hours to implement this functionality. Overall, I would say that it wouldn't be feasible given our constraints.
I should also mention that I have seen references to compromise solutions. Typically, they involve keeping all dates "as is" and adding a new field for "unknown date information" information to each record. The latter would list the date components which are dubious or unknown, i.e. the century, decade, year, month or date. It would be up to our software to convert entered values like "14..-00-00" to "1400-00-00/unknown decade and year" and then display them correctly. I don't have direct experience with this approach, but it looks reasonably straightforward. It shouldn't affect performance and it should take less time to implement than a complete date revamp. Still, it would be quite time consuming. Ahasuerus 12:22, 5 April 2018 (EDT)
Considering that there is a note field displayed close to to the dates on both author and title pages, putting date info in notes if it's inexact is probably enough. Maybe if there is both a date note and other notes, put the former alone on a separate line at the start of the notes. --Vasha 13:38, 5 April 2018 (EDT)
Maybe a checkbox for "approximate date" and another for BCE/CE?--Rkihara 14:34, 5 April 2018 (EDT)
Thanks for all the info, and sorry about all those worms crawling everywhere ! I like the idea of a checkbox which would solve part of the problem, for ca. dates anyway. Linguist 04:29, 6 April 2018 (EDT).
I can see how a checkbox for "approximate" dates would be useful. It would let us display the word "[approximate]" on Summary, Title, Publication, etc pages.
On the other hand, a "BCE" checkbox would be difficult to do right. We would need to modify all of our date comparison operations, reports, validation, etc to account for it. That's a lot of work for relatively little gain.
I suggest we copy the relevant parts of this discussion to the Community Portal to see if there are additional considerations that we may be missing before we create a Feature Request. Ahasuerus 10:43, 6 April 2018 (EDT)
I want to ask a slightly different question here - what do you want to do with these dates? If it is just for recording purposes, new fields and so on will work but if they need to be used for searching, we will start getting into the "do I search for fuzzy or for real dates" and "I am looking for books from the 1950s, why something from Dec 12, 1956 does not show up"... And yet another can of worms is opened.
So is the request to be able to record those dates or to be able to use them for something downstream?
PS: And for the record, switching from the date formats to string formats for all the dates so we can accommodate some fuzzy dates is like using a nuclear bomb to kill a fly - the fly will be dead but so will be a few billion other creatures in the vacinity...Annie 14:37, 6 April 2018 (EDT)
One purpose of having approximate dates would be to position titles more or less correctly in lists, instead of having a whole bunch of 0000-00-00 at the bottom. For seaching purposes, I think "Advanced Search" does the job perfectly (i.e., "Title Year starts with 195", etc.). The debate was really about having a checkbox for "approximate" or not, and if any other ideas could be expressed about it. Linguist 04:49, 7 April 2018 (EDT).
I believe there is an FR for a separate sequence field although I don't recall which or how it might affect known or partial dates. It was more for sequencing undated reprints within an ISBN. ../Doug H 13:53, 7 April 2018 (EDT)
There is no reason to expect fuzziness to restrict itself to the decimal system. The publication may be unknown within a span of 5 years (e.g. after book A but before book B) or could be two alternate dates, due to illegibility (e.g. is that a 3 or a 5?). All these require notes. As for what to enter - enter the earliest time for sorting. The 'approximate' flag could serve as an 'uncertainty' flag so someone with an accurate date looking for a match has a better idea of what might match their copy and let 2000-00-00 be the year 2000 and not 'somewhere in the 21st century'. ../Doug H 13:53, 7 April 2018 (EDT)

Notes and Annotations

Certainly we use the essay title "Notes ([publication title])" frequently when one of the publication contents is a section entitled "Notes". I don't believe we need to use it whenever a contribution is credited as "notes"; that is optional. Reading title search results for "Annotations", I infer we commonly use essay title "Annotations ([publication title])" for notes that are intermingled with the object text rather than printed in a separate section--inline, marginal, and footnotes. Possibly we do so, almost universally, by inference from publication titles such as The Annotated Hobbit (two Annotations titles, see T1321374). Has there been any discussion of these points or one of them? Should we have consensus anywhere?

Particular points

  1. We now have three "(annotations)" as postfix disambiguator; namely title records T1291452 1889325 2210432. Should we eliminate those, or use that form routinely under some conditions, instead of "Annotations (..."?
  2. For The Annotated Alice --in multiple editions from 1960, whose notes/annotations may be different-- we have only one Notes/Annotations title, the 1999 T1280641. That appears in no publication record, only carries a review in Locus, with 3 distinguished verifiers. Verifiers of this and other Annotated Alice publications have listed no such contents.
  3. This week I added 1977 Alice chapbook The Wasp in a Wig, in a single edition/format so far P659791 --originally with "Annotations (The Wasp in a Wig)" the only content by Gardner, and this note
"Preface, introduction, and notes by Martin Gardner" (entered as "Annotations")
(The other Gardner titles were already in the database, and I have since added them, also expanded the notes.)

--Pwendt|talk 14:52, 6 April 2018 (EDT)

Edit Form changes - 2018-04-07

A fairly big patch was installed about 10 minutes ago. It modified how our "Add" buttons work behind the scenes. There should be no user-experienced changes. If you notice anything unusual, please post your findings here. Ahasuerus 15:00, 7 April 2018 (EDT)

"Add" buttons are about to be moved

As per Roadmap 2017, we were going to:

  • Move “Add Authors/Transliterated Titles/etc” buttons to the right to free up screen real estate. This will become more important with the addition of new multiply occurring fields (see immediately above.)

It turned out to be a much more involved process than originally expected and required a time-consuming cleanup effort. On the plus side, the software has been improved and streamlined, which should make it easier for new developers to contribute.

We are finally ready to move the "Add" buttons; the main patch is about to be installed. Depending on your browser, you may need to do a full page reload (Control-F5 in most browsers) for the changes to appear correctly.

Please note that the originally proposed design has been tweaked. Instead of appearing to the right of multiply occurring input fields, Add buttons will appear to the right of the field label. Lets give it a few days and then we can tweak their location if needed.

Also please note that this change does not affect the "Contents" section of New/Edit/Add/Clone/Import/Export pages. That's a whole different can of worms which we can address later based on the feedback to the current change. Ahasuerus 20:44, 8 April 2018 (EDT)

Indeed, I think you will need to tweak the size, location, or appearance of the buttons, because they really don't look right at the moment. In particular, they are out of place when the browser window is horizontally narrow so that the label breaks onto two lines. --Vasha 21:02, 8 April 2018 (EDT)
Would it be possible to post a screenshot of the misaligned section? I think I was able to recreate the problem with "horizontally narrow" browser windows, but it would be better to make sure that we are seeing the same thing. Ahasuerus 15:39, 9 April 2018 (EDT)
Unfortunately I can't take a screenshot of what it looked like when I adjusted the window width on my laptop browser, because my laptop chose today to break down. However, as I recall, the fact that the button is a little larger than the label letters was affecting line spacing, and it looked kind of odd when the button wound up on a line of its own. You can notice this more on the author page because that has some long labels. --Vasha 16:39, 9 April 2018 (EDT)
Thanks, I think we are seeing the same problem with line wrapping on Edit pages. I looked into it a couple of years ago but was unable to make it display better due to browser inconsistencies and, most likely, my limited knowledge of HTML. I'll take another look to see if I can improve the layout. Ahasuerus 15:18, 10 April 2018 (EDT)
The position of the plus button for the External Identifier makes it very hard to work with - I keep hitting the question mark next to it instead on the small screens. Any chance we can remove that question mark? The content can go up on the label line with the rest of the external IDs notes. Annie 21:28, 8 April 2018 (EDT)
Sorry about that! It was actually a deliberate choice because it lined up better on my monitor. Alas, I don't have any portable devices to work with (and there are so many of them) and it's hard to predict what may create an unexpected issue.
I have added a space between the "+" signs and the mouse-over help. Does it look better now? Ahasuerus 22:40, 8 April 2018 (EDT)
I had not hit the question mark in the last hour or so so it appears to behave better. Will let you know if something changes. Annie 00:56, 9 April 2018 (EDT)
Nice! Ahasuerus 01:01, 9 April 2018 (EDT)
And I like how the plus sign is now moving to the latest line (earlier today it was staying always on the first line). Not that I have too many cases that need 3 or more IDs but it happens :) Annie 03:15, 9 April 2018 (EDT)
"The plus sign ... moving to the latest line" was part of the original patch, but it required a full page reload (Control-F5) because of JavaScript caching by most browsers. I suspect that your cache expired a few hours after patch installation, which forced the new code to be loaded :-) Ahasuerus 15:34, 9 April 2018 (EDT)
Ah, I see. Did not think to reload (did not know it was supposed to be different) - it was not bugging me too much and I was just churning through a cleanup report. Annie 15:41, 9 April 2018 (EDT)

(unindent) Help has been updated. Ahasuerus 09:19, 13 April 2018 (EDT)

The X in ISBNs

How easy would it be for the database to automatically convert lowercase "x" to an uppercase "X" upon submission? Right now, it gives a "bad checksum" error if the ISBN is submitted with a lowercase "x", even if it's correct with the uppercase "X". ···日本穣 · 投稿 · Talk to Nihonjoe 13:15, 10 April 2018 (EDT)

I think we have an FR for this, but I can't check at the moment because the ISFDB part of SourceForge is currently down. We couldn't (easily) do it in the past because ISBNs and catalog IDs shared the same field, but it should be doable now. Ahasuerus 15:09, 10 April 2018 (EDT)
And here it is -- FR 96. Ahasuerus 15:36, 10 April 2018 (EDT)
Done! Ahasuerus 17:43, 10 April 2018 (EDT)
Awesome! Such speedy service. :D ···日本穣 · 投稿 · Talk to Nihonjoe 18:11, 10 April 2018 (EDT)
We do our part! :) (Which would probably be a lot bigger if I were a few decades younger, but it is what it is. Perhaps, like the Terminator, I just need a vacation.) Ahasuerus 18:37, 10 April 2018 (EDT)
I love how you get (well deserved) kudos for speediness it only took nine years from the original creation of the FR (but hey it is hard to track and prioritize all those things). Uzume 15:09, 9 June 2018 (EDT)

Author/Title Language Mismatches report

We have Author/Title Language Mismatches pretty much under control lately. Maybe it is time to add the SHORTFICTION titles so we can start working on trying to match the different language stories to their parents (or find parents where we do not have them)? Any thoughts? Annie 15:16, 10 April 2018 (EDT)

I'll work on the Japanese ones as I have time. That's all that's on there right now. ···日本穣 · 投稿 · Talk to Nihonjoe 15:29, 10 April 2018 (EDT)
Yup - that's where the list I was bugging you about yesterday came from so you have these on your list already. :) Annie 15:34, 10 April 2018 (EDT)

(unindent) We can certainly add more title types to this cleanup report if we have editors who are interested in the project. Here is how many discrepancies of different types we have at the moment:

  • ANTHOLOGY: 265
  • CHAPBOOK: 505
  • COLLECTION: 1544
  • COVERART: 9157
  • ESSAY: 3262
  • INTERIORART: 6823
  • INTERVIEW: 116
  • OMNIBUS: 843
  • POEM: 330
  • REVIEW: 385
  • SHORTFICTION: 3989

Ahasuerus 15:35, 10 April 2018 (EDT)

The anthologies, collections, omnibuses and chapbooks may end up with a lot of ignores - they don't match between languages as easily but there will also need to be a lot of research to check if that specific one is not actually published in the native language (if we want to do it properly - we can also decide to ignore based on a quick glance). And I really do not care about the art titles (had enough of them when we were assigning languages, don't want to see them for at least a year :) ).
I'd say Short Fiction (they are more fun to work on)... Due to the number, shall we do the usual alphabet split an start with the first few letters of the alphabet? Annie 15:47, 10 April 2018 (EDT)
Sure, if there are no objections we can start with "A". Ahasuerus 22:15, 10 April 2018 (EDT)
Letter "A" has been added. Ahasuerus 23:17, 10 April 2018 (EDT)
Yey, Annie has a new toy :) Meanwhile, another report is about ready to bite the dust (some pure art books are just fine as multi-language ones). :) Annie 23:28, 10 April 2018 (EDT)

(unindent) Some preliminary thoughts after some poking around the stories last night - we have more than these ~4K, possibly a lot more. Between authors being set to English by mistake (or simply because all the stories were in English and no search was done) and authors with less than 4 stories that have no language attached to them (none of those will popup on the report), there are a lot more translated stories hiding in the lists. Some will pop up in the same publications where the report finds a story (or two); some will pop up later. But that whole thing will take a bit to clean :) It is fun though :) And it makes me go back trying to assign languages to authors - even for 1 or 2 works ones - because this is where these are hiding :) I guess that after dealing with works languages in 2017, 2018 is for dealing with authors... :) Annie 13:04, 11 April 2018 (EDT)

"Perfection is not attainable, but if we chase perfection we can catch excellence." :-) Ahasuerus 13:45, 11 April 2018 (EDT)

(unindent) Can we add some more letters here? Or if the numbers permit it, even all the stories? I know that we have quite a lot still left on the board but by now I had tried to find a parent for each of those left - I am not giving up but I can as well work on some easier ones while I dig on these. :) Annie 18:17, 6 June 2018 (EDT)

Thanks for working on this report! After running a few experiments I decided to include all of the eligible SHORTFICTION titles. It seems likely that the ability to review all problematic records associated with an author will be more efficient even though the report will now contain close to 4,000 titles. If it turns out to be unwieldy, we can go back to the old way of doing things. Ahasuerus 22:59, 6 June 2018 (EDT)
As long as it does not crash the server, it will be fine. :) I am already kinda doing exactly this - I hit one story and end up fixing a complete anthology or author. But having more stories identified will give me more footholds to get into those clusters of stories.  :) Annie 23:29, 6 June 2018 (EDT)
And after some major fixes (such as a few authors with wrong languages that dumped all their stories in the report and the 200 or so excerpts being ignored (because they will (almost) never be matched)), we are down to 3450 stories to find parents for (we had ~3800 after the regeneration). Not as bad as it could have been but unlike other reports, this one will be getting new titles almost nightly (from non varianted new titles and authors that get their languages set). The list is not unwieldy so we are all good. :) Annie 17:05, 7 June 2018 (EDT)
"I love it when a plan comes together"! :-) Ahasuerus 17:21, 7 June 2018 (EDT)

The Unteleported Man

Following a user's request and fitting the note (on the novel version) and the length I transformed the Ace Books publications of this PKD title from 1966 and 1972 into novellas. Stonecreek 00:00, 11 April 2018 (EDT)

Linking templates

At ISFDB.org we have numerous templates that generate hyperlinks. I have some trouble keeping them straight and finding them.

Some operate only in database records (at URL isfdb.org/cgi-bin ?), some only in the wiki (isfdb.org/wiki), some both.

{a}, for author, operates in both database and wiki, and to the same effect; it generates a link to an author Summary Bibliography in the database.
{publisher} operates only in the database

Help:Using Templates and HTML in Note Fields concerns the database and contains a table of templates that operate there, Help:Using Templates and HTML in Note Fields#Linking Templates. I suggest that it needs a header, which should link to the table, or category, of templates or linking templates that operate in the wiki.

Perhaps background colors or distinguishing marks can be added to the tables, which indicate whether the template generates a link to some database record, some wiki page, or outside. Among the database Linking Templates, if i judge correctly:

  1. {a} and {publisher} alone link to the database;
  2. Functionality="Displays the full name of this bibliographic source and links to it" (11 rows of the table) means "... links to its page in the ISFDB wiki", and no other templates/rows link to wiki pages;
  3. others link outside;
  4. except {tr} isn't a linking template. (Perhaps {tr| {a| Charles Baudelaire} } generates a message that links to author Charles Baudelaire.)

Is that right?

Meanwhile a table of linking templates that operate here in the wiki should have a header that links to Help:Using Templates and HTML in Note Fields#Linking Templates. And the same background colors or distinguishing marks should be used to classify wiki Linking Tempaltes as their targets are in the database, wiki, or outside. --Pwendt|talk 16:02, 11 April 2018 (EDT)

The Tr and ISBN templates are not linking ones - they are there to allow the standardization of the data entries in anticipation of the day when translators and multiple ISBNs will become part of the regular records (one day™). So think of them more as a preparation stage than anything else. Most of the linking ones exist so that we do not have changeable links in the DB - cleaning those is not a funny exercise and having the template allows for a single change when the other server change their formats :) Annie 16:10, 11 April 2018 (EDT)

Penguin Books and Penguin Books (US), for instance

Consider our two records of ISBN 978-0-14-310-762-0 print publications. The records need work at least in the Pages and Cover Artist fields. Suppose it done, and suppose the values in those fields match. (Amazon US and UK sites do now report the same data, including cover image file, and provide "Look inside" the same book apparently (same title leaf); whose title page indicates no location; whose t.p. verso gives the US address and reports printing in the US.)

Do we intend that publishers Penguin Books and Penguin Books (US) are used to carry the UK and US publication dates and list prices, for copies "the same book"?
On the contrary, should the difference between publisher names mean a difference between books? If so, must there be an interior difference? One evident from the title leaf, rather than, say, promotional material in the front and back pages.

Note that our Note on publisher Penguin Books notes that 'books published exclusively in the US should be entered as "Penguin Books (US)" '. In explanation it adds that "the US division started publishing books exclusively for the US market". What are the criteria for publication "in the US" or "for the US market"? Offhand, provision of a list price in UK currency, and prepublication listing of the book at Amazon UK, constitute publication for the UK market. Our note implies that publications (if not their database records) migrate from Penguin Books (US) to Penguin Books when we ascertain that it is for the UK market as well as the US market.

(This is not a book whose title page states something like Macmillan; London New York Toronto Sydney.) --Pwendt|talk 21:12, 11 April 2018 (EDT)

External IDs and book images

Two quick questions from my To Do list.

Many WorldCat library records provide a thumbnail image, usually showing a front cover or front jacket; commonly an image of that publication reported in the WorldCat record, and commonly otherwise. Are they stable? Should any such images be ignored? Or should we limit the External IDs field to OCLC of records where either (a) there is no image, or (b) we are able to say in a publication Note whether the image fits the book?

Amazon provides pages for many old books, some without much data. Should ASIN for such a page be reported in the External IDs field regardless whether the page at Amazon is currently a source for the publication record (including perhaps image only)? Whether that is useful depends, I suppose, on whether the page with URL determined by ASIN is useful to re-visit --most likely because that is where data (such as a book image) will appear in the future, most likely when another Amazon-affiliated dealer uploads it.

--Pwendt|talk 21:44, 11 April 2018 (EDT)

My thoughts:
Regarding OCLC - if everything else matches, I would link to the record (and if the cover differs, I would mention so). Restricting to non-image only records will remove a lot of good links in the system. So yes - images are great but they are less important than the rest of the details.
OCLC does not match images with records, only ISBNs. Thus if a book has been issued ten times with ten different covers but the same ISBN all records will show one image [likely of the latest printing]. The images are auto-generated from bulk files they purchase from external sources [four different ones, if I remember rightly] so they can't 'correct' images and they won't import individual images for particular records, either. I've had this discussion with their 'BibChange' department. For our purposes just totally ignore the images. --~ Bill, Bluesman 14:25, 2 May 2018 (EDT)
For the ASIN question - for pre-ISBN books, if the record does not look too shabby, I will add the ASIN. For books that have ISBNs, I would not add an ASIN link unless I am using the specific record as part of the source for the record even when the book is issued a B ASIN (the ASIN of an ISBN book should be the ISBN10 but there are some exceptions). Annie 22:51, 11 April 2018 (EDT)

Maurice Level - why do we have so many non-genre titles?

Maurice Level has 2 genre novels and a gazillion and seven non-genre titles (a lot of short stories in a search of parents). It seems like they made it into the DB as part of Centipede Press collections like this one but unlike some of the other similar publishers, Centipede does not publish just in the genre. Any reason not to delete the lot of them? Am I missing something here?I'd really rather not spend half the night looking for original titles if we are going to delete the lot anyway :) Annie 01:44, 12 April 2018 (EDT)

Some of those are in genre horror publications (Weird Tales, etc.) All of them are non-speculative horror. Up until a few months ago, they weren't marked non-genre; I went through the lot and realized that only the two novels were speculative. I certainly wouldn't object to removing things that aren't in genre magazines. But what about horror anthologies? Some editors (as Marty said in this discussion) prefer to include the complete contents of an anthology that's predominently genre. Conplete contents is standard policy for magazines, but there seems to be no clear agreement what to do about anthologies. --Vasha 04:14, 12 April 2018 (EDT)

My Recently Changed Primary Verifications - Catalog IDs added

"My Recently Changed Primary Verifications" has been modified to display Catalog IDs in the "Changed Fields" column. Ahasuerus 09:38, 12 April 2018 (EDT)

"Taste of Wrath" length

Does anyone know the exact word length of Taste of Wrath, which has been entered as a novel although described by publisher and author as a novella? --Vasha 13:45, 12 April 2018 (EDT)

It is a pre-publication addition which based on the number of pages was cataloged as a novel. This being Tor though, I suspect it may be a novella. We should probably wait for the first verifier on this one because it will be close to the limit between the two... (or a look inside from the Paper version of the book at least). I'd leave it as is but would a note in the publication to the future verifier to check the length (it won't be the first time Tor calls a novella a novel and vice versa when they are very close to the limit). Annie 14:19, 12 April 2018 (EDT)
For reference purposes, the printed version of All Systems Red, which was published by Tor.com a year ago, was 149 pages long. Checking my e-copy, I see that it contains 31,910 words. Assuming that all Tor.com's books use roughly the same font (not necessarily a safe assumption), the dividing line between their novellas and novels should be around the 200 page mark. Ahasuerus 14:42, 12 April 2018 (EDT)
I wish they did use the same font - it almost feels like they are trying for a certain thickness and decide the font based on that. I'd always used 200 as the cutoff as well but there is a chance that this one used the what I call "the novelette font" thus making it look bigger. Annie 14:48, 12 April 2018 (EDT)

URL duplication disallowed

As per FR 1138, duplicate URLs are now automatically compressed into one unique URL when entering data for a record. The same URLs can still be entered for different records, e.g. you can enter the same URLs for multiple different authors -- see Ilona Andrews, Ilona Gordon and Andrew Gordon whose author records share URLs. Ahasuerus 14:12, 12 April 2018 (EDT)

Potential Advanced Search enhancements

A recent discussion got me thinking about our Advanced Search functionality. Here is a list of things which have been requested over the years and which can be implemented relatively painlessly:

  1. "Advanced Note Search", a new section of the Advanced Search page. It would compare the entered search value against the Note field of all ISFDB records and display the results grouped by record type (author, publisher, title, series, etc.) We would need to decide how we would display the grouped results, but the core functionality shouldn't be hard to implement. The functionality would be helpful when looking for something that may exist in all Note fields, e.g. an author/translator name, Web site name/URL, etc.
  2. "Advanced External Web Site Search", a new section of the Advanced Search page. The functionality would be similar to the Advanced Note Search above: it would compare the entered search value against the "Web Page" field of all ISFDB records and display the results grouped by record type (author, publisher, title, series, etc.) The rationale is similar to the rationale behind the Advanced Note Search proposal above.
  3. Lifting the "3 search values per search" limit. Instead of displaying three input lines per Advanced Search type, we would display just one line followed by a '+' button. It would be similar to the way '+' buttons work elsewhere and allow entering as many search values as needed. (Only limited by the fact that Internet Explorer has issues with URLs which contain more than 2,047 characters.) Note that this change would require that all Advanced Searches would be forced to choose a single AND or OR condition. Mixing and matching multiple AND/OR conditions in arbitrary searches would either cause performance problems (best case scenario) or cause the search logic to hang and possibly crash the site (worst case scenario.)
  4. Adding Advanced Searches for currently unsupported ISFDB records, i.e.:
    • Advanced Series Search
    • Advanced Publisher Search
    • Advanced Publication Series Search
    • Advanced Award Type Search
    • Advanced Award Category Search
    • Advanced Award Search
    • Some of these search types would be more useful than others, but it would be nice to add all of them simply to make things consistent across the board. They are not hard to implement, so the added effort wouldn't be significant. The only concern that I can think of at the moment is that it would make the Advanced Search page too busy. We could address this issue in a couple of different ways. The easiest one would be to turn the Advanced Search page into a menu which would list all of the available search types. The user would then click the search type she is interested in and be taken to the Web page for that search type. Another way to handle the issue would be to display a single drop-down list with all of the search types. Once the user chooses the search type, the software would display the appropriate input fields and drop-down values. It would be similar to how the software dynamically changes the drop-down values for different advanced search criteria. The second way would require a bit more work than the "menu" approach, but it should be doable.

So, what do you think? Is (some or all of) the proposed functionality desirable? Is it high, medium or low priority? Ahasuerus 13:42, 13 April 2018 (EDT)

I'd love to have these but I am not sure that they are really high priority. Meanwhile, can we make sure that if the Advanced search for the Notes is implemented, it is easy to search for templates (the Tr one for example) :) Annie 13:52, 13 April 2018 (EDT)
I assumed that it would work the same way the three existing Advanced Search sections currently work. Is that OK or would you like to see different functionality? Ahasuerus 15:35, 14 April 2018 (EDT)
I never tried to used them to search for a template so let me go and play with that a bit. To explain what I am looking for: A translator's note shows up on the page as "Translated by X" in two different cases: when it is written like that and when it is written {{Tr|X}}. If I search "Translated by", will both cases be found or do I need to look for "{{Tr|" as well? Annie 16:00, 14 April 2018 (EDT)
Oh, I see. No, I am afraid we don't have "template expansion while searching" capabilities. It would be fairly easy to add, but performance would be abysmal unless we made matching database changes, and that would be rather hairy. Ahasuerus 16:39, 14 April 2018 (EDT)
Another argument for using the templates - easier to search for them :) Thanks for the confirmation :) Or we can finally get around and figure out a proper system for translators :). Annie 16:43, 14 April 2018 (EDT)
I would prefer the implementation of all the options above. I think structuring the Advanced search with a single drop-down list (like the regular search) would be best and ultimately be less complicated or confusing for the end user. I'd consider this a medium priority because of all the potential benefits for the end user. ···日本穣 · 投稿 · Talk to Nihonjoe 15:03, 13 April 2018 (EDT)
It wouldn't be a bad idea to have an array of different search type possibilities; and I think the drop-down list approach would be nicer than the menu approach. However, I think the search enhancement that would be really useful to me would be adding the ability to sort results by author. --Vasha 16:08, 13 April 2018 (EDT)
Right, FR 1046. It's an inherently non-trivial issue because a title/pub can have multiple authors. That said, the last round of enhancements to the Advanced Search software may have made a palliative/fuzzy solution more feasible. I will experiment with the code once I finish this round of Fixer updates. Ahasuerus 15:33, 14 April 2018 (EDT)
I would prefer the implementation of all. Last week, my first thought was that I would use only 1. and 4., and use 4. almost entirely for purpose of searching the Notes field in pages classified by type--expecting that because I now use the Advanced Search almost never for anything but the three available Notes fields (and Synopsis field of Title Search). Now I suppose that I would use 2. also, and it must be at least medium priority for the project.
How does clean-up effort proceed if not by effective search of all Web Pages and Notes fields for strings such as lib.umn.edu (when University of Minnesota libraries rearranges its website without redirecting old URL)? And for replacement of hand-made by template links, search of all Notes fields for strings such as LCCN: <a href and as ">LCCN ?
P.S. In the last sentence I mean successive simple searches of Notes. Compound search of the same field can be used to mimic search of that field for some regular expressions rather than simple strings only. For instance
  • Notes contain "publisher.cgi?" AND Notes contain "Macmillan"
(for all pages, with some false positives, that contain manual links to Publisher pages of Macmillans where "Macmillan" may or may not be the first or last word of the publisher name)? And to exemplify the same where templates are used, for instance
  • Notes contain "{pu" AND Notes contain "Macmillan"
--Pwendt|talk 17:25, 15 April 2018 (EDT)

(unindent) Thanks for the feedback! It sounds like all of the described features would be useful and that their priority is "medium". I'll go ahead and create Feature Requests on SourceForge. Ahasuerus 12:29, 16 April 2018 (EDT)

FRs have been created. Ahasuerus 12:55, 16 April 2018 (EDT)

Webpages links at the Internet Archive

University of Minnesota Libraries has revised its website heavily without providing useful redirects for URL at special.lib.umn.edu and probably others. I fixed one Author page by providing old URL with that of the replacement and, on search of the Webpages field for Author pages only, discovered that another editor has replaced one by providing URL for the old page at the Internet Archive (archive.org).

We have about 20 lib.umn.edu URL in Webpages fields of Author pages, about half at special.lib.umn.edu of which I recognize the majority as my contributions (usually pursued for people without Wikipedia-EN pages). I am happy to "fix" all those (and explore the other 10) on advice concerning whether the Internet Archive target is appropriate, given that the source has replaced the page.

The old page now available only? at Archive.org is more useful as a biographical source because the biographical sketch is prominent near the top ...

... whereas it is now hidden, who would know, under heading "Additional Description" (click to show), which is located down the page. On the other hand, our linkname "archives.lib.umn.edu" for the latter URL is more informative than "archive.org" for the former. And the official target is more useful to one who cares what lib.umn.edu has to say and to offer about the person generally. Among other things, it contains and should continue to contain current links to subpages, and others that the library may provide now or later. --Pwendt|talk 17:58, 15 April 2018 (EDT)

Any reason why we can't list both? ···日本穣 · 投稿 · Talk to Nihonjoe 00:19, 21 May 2018 (EDT)

Adding Low German

Hello everyone.

I was wondering whether it was possible to include Low German in the list of available languages. Granted, the literary output of this particular language, especially in the fantasy/scifi genre is sadly a bit lacking, nevertheless at least the first two Harry Potter books have been translated ("Harry Potter un de Wunnersteen" and "Harry Potter un de grulig Kamer"). --Giwerk 06:11, 16 April 2018 (EDT)

Our list of supported languages is based on the ISO 639-2 standard. Since Low German (aka Low Saxon) is an ISO 639-2-recognized language, I don't think there should be a problem. I will ping User:Linguist to see if he has any additional thoughts. Ahasuerus 09:27, 16 April 2018 (EDT)
No problem for "Low German (Low Saxon)" (or maybe "Low German/Low Saxon" ?). I usually make use of "Plattdeutsch" for my own purposes, but this might uselessly complicate matters. Linguist 04:31, 17 April 2018 (EDT).
I would prefer the term "Low German" since Niedersächsisch/Nedersaksisch/Neddersassisch/Neadersassisk nowadays usually refers only to (a part of) the West Low German varieties. Historically it was often used interchangeably to mean the whole of the Low German language as well; however, Low German refers only to the whole language and should thus be the preferred choice:
„Mit ,Niedersächsischʻ ist in unserem Zusammenhang ein Dialektverband im westniederdeutschen Dialektraum gemeint, der sich von den anderen westniederdeutschen Dialektverbänden, dem West- und Ostfälischen, durch eine Reihe sprachlicher Merkmale abhebt.“
– Stellmacher, Dieter (1981): Niedersächsisch. Düsseldorf: Schwann. 23.
„Niedersächsisch → Nordniederdeutsch.“
– Bußmann, Hadumod (2008): Lexikon der Sprachwissenschaft. Stuttgart: Kröner. 475.
„Man ist sich generell darüber einig, daß das Niedersächsische im Osten ungefähr entlang der ehemaligen innerdeutschen Grenze vom Ostniederdeutschen geschieden werden sollte [...]
Eine Isoglosse, die sich recht gut zur Trennung der niedersächsischen Formen vom Ostniederdeutschen eignet, bezieht sich auf die unterschiedlichen Verbindungen im Präsens Plural Indikativ. [...]
Alle wichtigen Teilgruppen des Niederdeutschen und Niederländischen können nach verschiedensten Kriterien weiter untergliedert werden. Im Niedersächsischen lassen sich beispielsweise das Nordniedersächsische, das Westfälische und das Ostfälische unterscheiden. Die niedersächsischen Dialekte werden gelegentlich unter der Bezeichnung ‚Westniederdeutsch‘ zusammengefaßt, wobei Niedersächsisch für all jene Mundarten steht, die wir als die ‚nördlichen Mundarten‘ des Niedersächsischen erwähnt haben.”
– Barbour, Stephen & Stevenson, Patrick (2012): Variation im Deutschen: Soziolinguistische Perspektiven. Berlin/New York: Walter de Gruyter.
The Dutch draw the line a little differently than the Germans:
„Het Nedersaksisch omvat in Nederland het gebied in het Noordoosten, dat wil zeggen de provincies Groningen, Drenthe, Overijssel en een deel van Gelderland en in Duitsland de Westnederduitse taalregio. ‘Nedersaksisch is eenvoudig een ander woord voor Oostnederlands en Westnederduits tesamen’ (Bloemhoff e.a. 2008: 54)”
– Maas, Sabine (2014): Twents op sterven na dood?: Een sociolinguïstisch onderzoek naar dialectgebruik in Borne. Münster: Waxmann. 18-19.
„In Engelstalige context heet het Nedersaksisch Low Saxon‚ in het Frans bas-saxon en in het Duits noemt men het Sassisch, Westsassisch of, ‘onvertaald’, Nedersaksisch. In de Nedersaksische gewesten zelf zegt men Nedersaksisch, evenals in het Fries. Om het Nederlandse Nedersaksisch en het Duitse (noordwestelijke) ‘Niedersächsisch’ te onderscheiden spreekt men wel van West-Nedersaksisch en West-Nederduits (zie ook Niebaums bijdrage over het Oostnederlandse taallandschap); als overkoepelende benaming voor beide gebruikt men in ons land wel ‘Nedersaksisch’, terwijl Peters (2003) daarvoor in het Duits ‘Sassisch’ hanteert.”
– Bloemhoff, Henk (2008): Taalsociologische aspecten. In: Bloemhoff, Henk & Kooi, Jurjen (eds.): „Handboek Nedersaksische taal- en letterkunde”. Assen: Van Gorcum. 296.
„Nedersaksisch is een benaming met een taalhistorisch bepaalde inhoud voor de nu ook staatkundig gescheiden realiteiten Oost-Nederlands en West-Nederduits, die echter geen van beide en niet tezamen ooit een in zich besloten identiteit gekend hebben.”
– Niebaum, Hermann (2003): Regio, taal en politiek. In: Duijvendak, Maarten Gerrit Jan (ed.): „Regionaal besef in het Noorden”. Assen: Van Gorcum. 91.
On a side note, I prefer Niederdeutsch over Plattdeutsch, since Platt refers to a number of different Low and High German varieties. --Giwerk 07:52, 17 April 2018 (EDT)
The English term "Low German" seems like the best way to cover all that. "Low Saxon" isn't used much, and only by people who are also familiar with the the term Low German.
Another book to add would be Alice ehr Eventüürn in't Wunnerland. Looking through Amazon... Hanne Nüte un de lütte Pudel: 'Ne Vagel- un Minschengeschicht sounds promising [update: I found a description, and it's not spec]. There are picture books: Claas op Reisen, De Finnvoss. There are marginally relevant things like books of fairy tales and some medieval writings such as religious legends and Reynard the Fox. And, oh yeah, there is also a translation of Alice into Mennonite Low German/Plautdietsch, the language of some 400,000 people in Mennonite communities of South and North America... Vasha 08:16, 17 April 2018 (EDT)
One thing to keep in mind is that some of our data comes from library catalogs and other secondary sources, some of them quite old. If older sources use "Low Saxon", then it would be useful to make the name of the language "Low German/Low Saxon" to make it clear to our editors what they need to choose when they come across "Low Saxon". We used the same logic when we added "Asturian/Babel". Ahasuerus 10:11, 17 April 2018 (EDT)
I see your point, but that is a slippery slope. By that logic you would have to call it "Ukrainian/Little Russian" for instance. --Giwerk 11:01, 17 April 2018 (EDT)
Since we follow the ISO 639-2 standard for languages, our options are limited to what is listed in their tables. For Ukrainian, the only ISO 639-2-supported option is "Ukrainian". For Astuarian, the ISO 639-2 options are "Asturian; Bable; Leonese; Asturleonese". We decided to go with the first two because the last two were unlikely to come up in secondary sources. For Low German the listed options are "Low German; Low Saxon; German, Low; Saxon, Low", so we can do either "Low German" or "Low German/Low Saxon". I am not sure whether "Low Saxon" is used by secondary sources. Ahasuerus 11:56, 17 April 2018 (EDT)

(unindent) OK, "Low German" has been added. I'll also update Help to explain that we use the ISO 639-2 standard and that any alternative language names should be looked up in the online tables of ISO 639-2-recognized languages. Ahasuerus 11:14, 19 April 2018 (EDT)

Development server update

The development server is experiencing hardware issues. If I disappear for a few days, it probably means that I am in the process of rebuilding it. Ahasuerus 08:44, 17 April 2018 (EDT)

The failing part has been identified. A replacement has been ordered, but will take a few days to arrive. Hopefully the ailing component will hold out until then. Ahasuerus 14:01, 19 April 2018 (EDT)
The failing part has been replaced. Fingers crossed. Ahasuerus 18:40, 25 April 2018 (EDT)

Why is this book labeled non-fiction? And should it be corrected?

Hello, I stumbled upon The Book of Were-wolves and noticed it was labeled non-fiction. While cursorily reading through the electronic excerpt on amazon.com, this struck me as odd, and I feel this should rather be spec fic instead. Suggestions? MagicUnk 13:44, 25 April 2018 (EDT)

This book can be read in the entirety at Sacred Texts. It is a historical account of ideas about werewolves and related beings in Europe, quoting from documents and folklore collections. It is not fiction: Sabine Baring-Gould contributed no original stories to it, and although he quotes from legends and old sagas, these quotes (mostly from anonymous tellers) would not be the kind of fiction that is indexed in this database unless the legends were retold by literary writers, which they are not in this book. In fact, it is not really the kind of nonfiction that is included in this database either, since it is concerned with real beliefs, historical incidents, and Baring-Gould's speculations about the factual basis behind lycanthropy; this database normally only includes nonfiction that is about fiction. I would speculate that it was included because it is a source for many pieces of fiction. Does anyone else have ideas about why it is included and whether it should be kept? (No one has verified it.) --Vasha 15:18, 25 April 2018 (EDT)
I guess it's because of the topic that relates to a popular theme, in combination with the author who has an entry in the Encyclopedia of Fantasy. Stonecreek 15:50, 25 April 2018 (EDT)

URL validation changes

The URL validation process has been adjusted to ensure that all entered links to third party sites start with "http://" or "https://". Ahasuerus 17:37, 3 May 2018 (EDT)

Now no one can publish bibliographies on gopher and ftp... Uzume 15:12, 9 June 2018 (EDT)
You can add them to the notes if someone does.

Submission review page changes

The submission review/history page has been changed. The Contents section has been enhanced to display existing titles as hyperlinks. For example, you can click "Wolf House" or "Vampire Hollows" in the Regular Titles section of this recent submission. Ahasuerus 21:37, 3 May 2018 (EDT)

Something got really broken somewhere. See: this one Annie 22:53, 3 May 2018 (EDT)
Fixed -- sorry about that. I have been under the weather all day but figured that I should be able to take care of simple bugs and FRs. Apparently not... Ahasuerus 23:21, 3 May 2018 (EDT)
Thanks :) Take care of yourself! Annie 23:28, 3 May 2018 (EDT)
Thanks. Trying to. Ahasuerus 19:18, 5 May 2018 (EDT)

ISFDB downtime - 2018-05-05 @7:15pm

The system will be briefly unavailable starting at 7:15pm server (US Eastern Daylight) time. It should be back up within a few minutes. Ahasuerus 19:03, 5 May 2018 (EDT)

Everything should be back up. The "Content" field (used by omnibuses) has been adjusted to support up to 254 characters. Ahasuerus 19:18, 5 May 2018 (EDT)

Minor tweak to transliterated titles of reviews

The way our software displays reviews with transliterated titles has been adjusted. The transliterated titles associated with the reviewed record are no longer displayed. Only the transliterated titles associated with the review record are displayed within the mouseover bubble. Ahasuerus 16:21, 8 May 2018 (EDT)

Import/Export Content changes

The Import Content page has been upgraded to use the same "+" sign layout as the rest of our pages. Commas are no longer supported as delimiters.

In addition, the size of the input fields on this page and on the Export Content page has been adjusted to support the display of full URLs. Help has been updated. Ahasuerus 16:06, 9 May 2018 (EDT)

While I understand that the plus sign format is easier to work with and less prone to errors, I wish we could have kept the commas format - I was using it a lot on big imports (assembling the list beforehand and then just pasting it on the import). Oh well, Need to rework my usual process. Annie 13:26, 15 May 2018 (EDT)

Title page bug fixed

The bug which caused publication records to appear twice on the Title page has been fixed. It affected publications which included parent-variant title pairs. Bilingual publications and publications with COVERART/INTERIORART pairs were the most common subset. Ahasuerus 20:50, 11 May 2018 (EDT)

Unmerge bug fixed

An unmerge bug has been fixed. It affected titles which appeared in the same publications as their variant(s). If you seen anything wonky during unmerge operations, please report your findings here. Ahasuerus 20:52, 11 May 2018 (EDT)

typo for José González Navaroo

I notice that in the page for the illustrator José González Navarro, whose wikipedia page is here, the surname is typoed Navaroo. I don't see any easy way to check any of the publications. But should the page be corrected anyhow? --Vasha 20:54, 11 May 2018 (EDT)

Your link does not work - you have a missing space :) I fixed that above. Considering that the author has all its accents, I wonder if it was ever edited and thus broken (in which case we probably should fix it). I think that authors updates keep older versions in the DB - not sure for how long though. Let's see what we can discover before "fixing" it - after all even if it is a wrong name, if that is how he is credited, we keep it this way :) Annie 13:33, 15 May 2018 (EDT)
Let me check submission history... Ahasuerus 15:09, 15 May 2018 (EDT)
The earliest "Navaroo" submission is this NewPub for Robert W. Walker's Search for the Nile and [this NewPub for Richard Glatzer's Quest for the Cities of Gold]. The English pubs are not verified, but 12 of WorldCat's records have the same typo, so it's possible that our data comes from WorldCat. The next question is whether the typo is in the books themselves or whether it's a cataloging artifact. We have two verified Polish translations with the same interior art, but the verifier hasn't been active in over a year.
Also, this José González's bio data matches our other Jose Gonzalez author record. This Web page makes it clear that he was responsible for the Vampirella comics and, by extension, the covers of our Vampirella novelizations written by Ron Goulart. Ahasuerus 15:57, 15 May 2018 (EDT)
P.S. At one point we tried to capture edit history for author records. However, later on we discovered that the design was flawed and had to abandon the effort. I expect that a new, better designed, version will be implemented once we have Publication History ready. Ahasuerus 15:57, 15 May 2018 (EDT)
Considering the Polish records, I am kinda in favor of leaving it as is... and pseudonyming and adding notes explaining the WorldCat thing and moving the data on the Gonzales page... It is possible that they were created by importing the English art and were later fixed but who knows... Thoughts? Annie 16:16, 15 May 2018 (EDT)
The Union Catalog of Polish Research Library Collections confirms "Navaroo", so I agree that we should keep it. Ahasuerus 16:39, 15 May 2018 (EDT)
PS: I just remembered you saying something about author records being recoverable (or something) thus asking. Thanks for digging this out. Annie 16:16, 15 May 2018 (EDT)
Um, maybe the person who illustrated Bantam's Time Machine books isn't the Vampirella cartoonist but somebody else? And maybe his name is really spelled Navaroo, unlikely as that seems? --Vasha 01:07, 16 May 2018 (EDT)
Maybe - and as you started the conversation, if you do not think they are the same, we can just leave it as is:) We should move the information from one of the author records to the other at least :) Annie 01:14, 16 May 2018 (EDT)
So, how about this: 1. Add info to Jose Gonzalez. 2. Remove info from J G Navaroo 3. Put a note on the Navaroo page explaining where the credits come from, and saying that this might be the same person as Gonzalez, with a link to that page. ,--Vasha 16:07, 16 May 2018 (EDT)
All cleaned up, moved around, commented and so on. Annie 19:47, 16 May 2018 (EDT)
That's great, thanks. --Vasha 21:22, 16 May 2018 (EDT)

Book by country

[Copied from my Talk page]

Hello Ahasuerus, is possible add the option to separate every book/author by country? Example: book A Máquina do Tempo. Original language and Country: English, UK. This edition: Portuguese, Brazil. And so on (also make a "country directory" by author and "country directory" by book).

And in this and this lists also make explicit from which country every title/author is. Example:

Titles by language

  • English: 1,177,543
    • US: X. number
    • UK: x. number

What do you think?

Thanks, ErickSoares3 16:57, 13 May 2018 (EDT)

I suspect that it wouldn't be feasible. There are many publications which are published for distribution in more than one country, e.g. US/Canada, and there are many authors who live and work in multiple countries (from Raspe to Nabokov.)
That said, we may want to keep this idea in mind when we start thinking about beefing up our publisher data. Ahasuerus 19:04, 13 May 2018 (EDT)
It's not exactly what's requested, but it might be possible to do something close (and "automatic") for the subset of publications with ISBNs. There could be something like a sorted (and annotated) view/report of an author's ISBNs and/or a title's ISBNs. Most of the agencies are country-specific, and if memory serves me, the English language "agency" has sub-groups/ranges for different countries (although maybe not all of them are completely separated). --MartyD 21:55, 13 May 2018 (EDT)
An interesting idea. Our software is already aware of "national", i.e. country-specific, ISBN prefixes: 607 is Mexico, 9961 is Algeria, etc.
However, we'll need to figure out how to handle "language" ISBN prefixes which do not map onto countries. For example, "978-3" is a language prefix used in Austria and Germany as well as in parts of Switzerland and Belgium. Similarly, "978-2" is a language prefix used in France as well as in Quebec. (On the other hand, "979-10" is apparently a national prefix limited to France, so it can get complicated.)
Finally, there are "regional" ISBN prefixes which cover multiple countries, e.g. South Pacific and some Caribbean islands. Ahasuerus 11:07, 14 May 2018 (EDT)
So how about pulling at least the ones we know about? Other from that - I think that we should be attacking that from the publisher angle, not the ISBN one - we need "country" and "language" multi-fields in the publishers - while there are a few that work across country lines (US/Canada; US/UK and the German-speaking, French-speaking, Spanish-speaking, maybe Portuguese as well and inside of the old federations (USSR and Yugoslavia), most publishers stick to their own countries and a handful of languages. :) And we need to figure out something for the multi-country ones (maybe). Annie 13:24, 14 May 2018 (EDT)
We could certainly create a new "statistics" report to show a breakdown of our publications by ISBN prefix. It would contain two parts, one for "language" ISBNs and one for "national" ISBNs.
We could also create a new author-specific biblio page, something like "Publication Summary". It would show a breakdown of different title types by ISBN language/country as well as by publisher.
Anything more involved, especially anything that would require creating new fields, would need additional design work. Publishers are a tricky area and may need to be redesigned at some point, e.g. to support co-published books and imprints. Ahasuerus 14:30, 14 May 2018 (EDT)
Agree that it needs a new design (and when we get there, there is also the ability to tie an ISBN to a publisher (think the Russian multiple ISBNs) and so on. I was just thinking aloud :)
I would love to have those stats by the way - seeing what publishers had published an author without the need to open each record is an interesting data point. In the meantime, I had been adding a note in the publisher notes about their location when I know it (for the non-English ones mainly) just so we do have the datapoint when we get to it. Annie 14:59, 14 May 2018 (EDT)
Looks like we can get the country-specific breakdowns (in painstaking fashion, unfortunately, from https://www.isbn-international.org/agencies . For example, if you look up United States or Germany, it will show you the sub-groups assigned to that country from within the language groups. I'd be willing to collect and encode that information, if you decide you want to go there. I think I'm responsible for the current state of the ISBN handling anyway. --MartyD 22:45, 14 May 2018 (EDT)
I see. Yes, "painstaking" sounds about right.
I guess the first thing to do would be to determine how stable the current system is. Does the agency assign new blocks to different countries on a regular basis? Does it reassign unused blocks? Do publishers sell subsets of their assigned blocks across borders? Etc.
Also, converting the ISBN field to a "multi-field", as Annie called it earlier, is one of the 2 "big" FRs on my to-do list. We may want to wait until it's been implemented before we start adding more ISBN-related features. Ahasuerus 16:13, 15 May 2018 (EDT)

Audible and ASIN

Although Audible is part of Amazon, they use their own ASINs. The Audible ASIN is not foundable in Amazon. The Amazon one is not foundable in Audible. Each Audible book has an Amazon one and an Audible one. And audiobooks are more and more popular. Example: "Brave New World" is B002V1BVK4 in Audible and B0012QED5Y in Amazon. Amazon knows how to connect them (so both sites know I have it) but you need the correct ASIN to find the book on their respective site (there may be an API connection somewhere). Can we either add Audible to the list of External IDs or add a template for the comments? I had been adding it just as a string, thinking about starting to make links but thought I should stop by and ask. :) Annie 13:38, 16 May 2018 (EDT)

It sounds like "Audible ASINs" are a separate type of third party identifiers. If so, then we definitely need to add them to the drop-down list. We can also create a new Notes template ("Audible-ASIN"?) if desired. Ahasuerus 14:24, 16 May 2018 (EDT)
Yeah, they are separate (annoyingly so) although they seem to be coming from the same pool and Amazon keeps track of them all - it just does not use them in searches across the two sites. :) We can add the template just for completeness (we have all of the rest as templates as well). My link above is the minimum URL you need for a link btw :) Annie 14:28, 16 May 2018 (EDT)
OK, FR 1147 has been created. I'll wait a couple of days before I tackle it in case other editors have additional concerns. Ahasuerus 14:44, 16 May 2018 (EDT)
The changes have been made. I will update Help shortly. Ahasuerus 11:33, 18 May 2018 (EDT)
Help has been updated. Ahasuerus 11:42, 18 May 2018 (EDT)
Thanks a lot. Annie 12:04, 18 May 2018 (EDT)
Sure thing. At some point we may want to create 2 new bureaucrat-only options -- "New External ID Type" and "Edit External ID Type" -- to make updates less time-consuming and error-prone, but it's a low priority. Ahasuerus 14:59, 18 May 2018 (EDT)
May be a good idea - we are bound to get more of these while we keep adding more and more international titles. On the other hand though, we probably should start thinking about the length of that dropdown as well - it is not really bad yet but if we add a lot more, it will get unwieldy. But none of those is anywhere near the priority list. :) Annie 15:08, 18 May 2018 (EDT)
OK, FR 1148 has been created. Ahasuerus 13:40, 19 May 2018 (EDT)

2018-05-18 downtime -- 11:30 am

The ISFDB server will be down between 11:30am and 11:35am server (US Eastern) time. Ahasuerus 11:20, 18 May 2018 (EDT)

Everything should be back up. Ahasuerus 11:32, 18 May 2018 (EDT)

Author or Authors - moved from R&S

On the title page appears "Author" on the publication page "Authors". Better is "Author[s]" for both pages.--Wolfram.winkler 05:44, 7 May 2018 (EDT)

No comment?--Wolfram.winkler 15:17, 18 May 2018 (EDT)
It is in the wrong forum - so people kinda missed it I suspect. Yes, that can be standardized via the usual way - a FR and then implementation :) Annie 15:29, 18 May 2018 (EDT)
One way to handle this issue would be to make the software more intelligent. We could display "Author" (or "Editor" for anthologies, magazines and fanzines) if there is only one author and "Authors" otherwise. We could also make similar changes to the logic behind the labels of other "multi-fields" like "Webpages". Consistency will become more important as we upgrade more fields (like the ISBN field) to support multiple values. Ahasuerus 17:41, 18 May 2018 (EDT)
In the meantime, can we at least add a "s" to the field name in the Title page? :) Annie 18:01, 18 May 2018 (EDT)
Checking the title page code, I see that it already checks the number of authors/editors and displays "Author", "Authors", "Reviewer" or "Reviewers" accordingly. It also displays "Editor(s)" for anthologies (but not magazines or fanzines.) It doesn't handle "Interviewee(s)" correctly.
I think we should correct the title page code and then make the other pages behave similarly. Ahasuerus 18:16, 18 May 2018 (EDT)
Sounds like a plan. FR creation time? Annie 18:40, 18 May 2018 (EDT)
I would suggest waiting a day or two to see what other editors think. Ahasuerus 18:48, 18 May 2018 (EDT)
I like the idea to make the software more intelligent and recognize if there are more than one in the field. ···日本穣 · 投稿 · Talk to Nihonjoe 19:14, 18 May 2018 (EDT)
FR 1149 has been created. Ahasuerus 09:52, 21 May 2018 (EDT)
Done. Ahasuerus 17:48, 2 June 2018 (EDT)

New LCCN Cleanup Report Request

Publications that have the word LCCN in the publication note, do not have {{LCCN (the templates) and do not have an LCCN external identifier. The first two conditions are easy enough to handle via the Advanced Search but I cannot figure out how to tie the last one and there are too many of those because of the LCCN being physically printed in the books (if someone gives me an Advanced Search query, that also works). That needs "ignore" for the cases where the note says that there is no LCCN number. Restricted to 500 at a time (there are more than that). We will need the same for OCLC when we deal with the OCLC links but we are probably a year away from that - all the LCCN links should be gone this week.

This will allow to get all non-linked LCCNs and either move them (if they belong to the title) or template them (if they are for a series or for an earlier edition). Annie 13:21, 21 May 2018 (EDT)

Sounds reasonable. I'll take a closer look later today. Ahasuerus 17:59, 21 May 2018 (EDT)
Thanks! Annie 18:13, 21 May 2018 (EDT)
As of last Saturday morning, there were 4,607 publications with "LCCN", no "{{LCCN|" and no LCCN external ID. I should be able to create and deploy a new cleanup report tonight. Ahasuerus 17:56, 22 May 2018 (EDT)
There will be considerably less in the live DB - I cleaned around 1K LCCN links since Sat - we were down to the last 431 as of last night and I am still chipping at them. (unless you already ignore the links in the report). But it is still manageable even if you exclude them already. Can you make sure you give me an ignore option, please? :) And thanks! Annie 18:09, 22 May 2018 (EDT)
Done! The data will become available around 1:30am server time. Ahasuerus 19:31, 22 May 2018 (EDT)
You are a treasure :) Thanks! Annie 19:33, 22 May 2018 (EDT)
Worth my weight in Ether ! :) Ahasuerus 20:18, 22 May 2018 (EDT)
P.S. All of our "first 500" reports have been changed to retrieve pubs alphabetically. Ahasuerus 00:17, 23 May 2018 (EDT)
That sounds logical. Thanks for the warning - would have wondered what's up when the OCLC report gets unstuck from the S (the IDs above 30K) it is on now. :) Annie 00:29, 23 May 2018 (EDT)
The only drawback of the alphabetical order is that it puts the special characters first - and in our DB, non Latin characters are special characters. So all the Cyrillic, Japanese, Chinese and other exotic scripts show up first in the translation reports - I need to work through all/most Japanese short stories before I can get to the rest. It had been fun though - so just an observation. But if I get stuck, we may need to do something about that specific set of reports... :) Annie 14:50, 26 May 2018 (EDT)
It would be easy enough to start the list with "A" -- just say the word. Ahasuerus 19:16, 26 May 2018 (EDT)
Let me see what I can do with the Japanese titles first - I had quite a lot of fun last night and some of the usual sources I've used before are very useful. If/When I get stuck, I will ask for finding a new starting point. Plus I can clear all of the Russian/Bulgarian/Serbian and other Cyrillic ones easily enough. Surprisingly enough, the most stubborn titles when I am researching so far seem to be the French ones :) Annie 19:25, 26 May 2018 (EDT)

Missing Translators Cleanup Report Request

Non-art titles with a parent in a different language and with Notes that do not contain {{Tr. Let's start with Novels and then we can add the shorter works and the containers. 500 titles at a time (as I suspect we have a lot more than that).

I keep stumbling upon clusters of translations from different hands that had been merged way back when. This will allow them to be split and the records to be cleared (and translators to be identified). As we keep adding more and more international titles, the sooner we get around to it, the better. Thanks! Annie 13:21, 21 May 2018 (EDT)

We can do that, but what would be the desired Notes format for uncredited and/or unidentified translations? Ahasuerus 17:59, 21 May 2018 (EDT)
We had a bit of a discussion earlier :). Two new templates will make everyone's life easier. But if not possible or desired, we can make do with the existing template and additional notes. Annie 18:13, 21 May 2018 (EDT)
I have run a few queries and found that we have roughly 30,000 translated titles which use some form of "Translated by" instead of the "Tr" template. Would it be better to have a separate cleanup report for them or should they appear on this report? Ahasuerus 16:05, 22 May 2018 (EDT)
Separate reports is better I think - they will require less research (except for the clusters that is). And then a catch all for all that are not on that report and that still have separate languages. Annie 16:17, 22 May 2018 (EDT)
In that case I think it may be better to add and sort out a cleanup report for "Translated vs. {{Tr|}}" issues first. That way they won't confuse things when the other requested report is implemented. Ahasuerus 16:27, 22 May 2018 (EDT)
Works for me - it will take awhile but we really should get those sorted and cleaned up :) At least with them being titles, I will stop spamming everyone (the LCCN/OCLC cleanup sends gazillion of PV notifications) :)
Approximately how many do we have that are with separate languages and do not have Translated variations in their notes? Annie 16:35, 22 May 2018 (EDT)
There are 40,192 translated variants without notes. In addition, we have 623 translated variants which have notes but the Note field doesn't contain the string "translat". Ahasuerus 17:31, 22 May 2018 (EDT)
So ~70K translated titles that need an update. That will be a looong project :) The big messes will me in these 40,192+623 ones... :) I almost feel like we should code both reports at the same time - the moving from Translat to the Tr template will be mostly mechanical but there is a tone of them and I really would like to work on the ones that do not have the string. What do you think? Can we code the two so they do not step on each other's toes? I almost can work the "translat" ones off an Advanced search even... Annie 18:05, 22 May 2018 (EDT)
So how about reversing the logical order and get these 40,192 + 623 on a report, filter for type (get just the novels first) and number (500 at a time) and start there? Annie 18:05, 22 May 2018 (EDT)
Sure, we can create 2 separate cleanup reports. Let me see what I can do tomorrow morning... Ahasuerus 21:02, 22 May 2018 (EDT)
OK, the cleanup menu has a new section, "Translations". Once the nightly process run tonight, it will two new cleanup reports.
In addition, the "Author/Legal Name Languages" sections have been merged. Various "Transliterated" menu sections have been merged as well. Ahasuerus 15:27, 23 May 2018 (EDT)
It also highlights the fact that we need to discuss a translator's system design at some point... I will shut up now :) Annie 18:05, 22 May 2018 (EDT)
You are excluding the art titles, right? Annie 16:17, 22 May 2018 (EDT)
I am, but we have very few art records which say "Translated by" -- here is one map example. Ahasuerus 16:27, 22 May 2018 (EDT)

SFWA Bulletin Index, 1965-2018

I just wanted to let you know that the complete index to the SFWA Bulletin is now live at http://sfwa.org/bulletin-index/.

--Michael Capobianco

Thanks! Ahasuerus 06:59, 22 May 2018 (EDT)

Help needed: Philadelphia {correction: Pittsburgh] Courier

Sue to needing to link a review in the latest F&SF, I would like to add The Beast of Bradhurst Avenue, by Samuel I. Brooks, to the database. It has not appeared in book form but was serialized in the weekly Philadelphia Courier from March 3 to May 12, 1934. Newspapers.com has that paper; does anyone here have a subscription to Newspapers.com or another way to look at the back issues? --Vasha 11:10, 22 May 2018 (EDT)

Do you have a university library nearby? They often have a subscription. Some city or county libraries also have subscriptions. ···日本穣 · 投稿 · Talk to Nihonjoe 13:28, 22 May 2018 (EDT)
During March 1934 that serial appeared in a famous newspaper, The Pittsburgh Courier (perhaps your clerical error?), which is available to me during university library sessions via ProQuest Historical Newspapers (proquest.com).
And there is no Philadelphia Courier in World Newspaper Archive (newsbank.com)
Today I can do no more than check the 1934 Pittsburgh Courier image quality in that archive, and check for appearance in another of its newspapers --and that only after a much delayed coffee break. ... --Pwendt|talk 16:03, 22 May 2018 (EDT)
Yes, of course it's Pittsburgh. Thanks for the offer! --Vasha 17:04, 22 May 2018 (EDT)

Particular notes: see User talk:Vasha77#The Beast of Bradhurst Avenue.

General issues

Are there any guidelines concerning Primary Verification from online images of a daily/weekly newspaper? (I have noticed that serial stories in daily newspapers of 100 years ago are commonly published once a week anyway, as in a special section that is weekly.)

Re Permanent and Transient verification, would I be advised or expected to verify Primary Permanent and downgrade that to Primary Transient if/when I relocate from convenient access to the university library, or The Pittsburgh Courier drops from its subscription, etc? --Pwendt|talk 17:47, 22 May 2018 (EDT)

Do we have examples of Primary Verification from online archives of newspapers (full view of numbered pages at least)? As 'newspapers' I have in mind not only traditional dailies such as The New York Times but other periodical publications that begin with interior contents rather than a printed cover or wrapper. So that the publication Cover field is not applicable; perhaps it should always be empty in practice.
The archive copy of a newspaper is routinely complete, or lacks some "insert" sections only. In contrast the archive copy of a book, as at HathiTrust Digital Library, is commonly lacking the covers and some front and back pages (if not more, e.g. all blank pages). Contrast also the bound volume of a magazine as a material archive that routinely lacks covers and perhaps some front or back pages. The archive of a newspaper, so defined, is not subject to some major obstacles to reliable verification of a book or magazine publication from its online archive copy. --Pwendt|talk 14:17, 9 June 2018 (EDT)

Variants of COVERART titles

Here are three publications that I added to the database this month.

  • Alice's Adventures in Wonderland, 1907 P664113
  • The Illustrators of Alice in Wonderland and Through the Looking Glass, 1979 revised ed. P666646
  • The Illustrated Alice in Wonderland, 2015 P644570

If I understand correctly, the 2015 COVERART should be booked as a variant of the 1979 COVERART, although the 1979 and 2015 are publications of different works. And notes about that illustration should be gathered, to some degree, as title Notes of the 1979 COVERART (parent title).
Right?

The three publication records and two coverart title records are much complicated now because the Baldwin Library copy of that 1907 Wonderland is missing several pages, and I have no other source; in turn, details of the artwork's original publication as interiorart are unknown. The Baldwin copy lacks two of 8 reported colour plates, or even two interior plus one frontispiece, and part of the Illustrations list(s). (As point of entry, see the 1907 List of Illustrations, incomplete online for b/w drawings only.)

Suppose it were confirmed that the latterday cover illustration is that of the missing 1907 frontispiece, there with the caption "Off with her head!". Then the parent title record would be 1907 INTERIORART, entitled as one of these alternatives

  • fp • "Off with her head!" (frontispiece)
  • fp • Frontispiece (Alice's Adventures in Wonderland)

and both the 1979 and 2015 COVERART titles would properely be booked as its variants.
Right?

--Pwendt|talk 13:22, 23 May 2018 (EDT)

The particular illustration featured yesterday --by Charles Robinson depicting Alice and the Queen of Hearts, with other Hearts-- has been used as coverart for a couple of different works, neither the Wonderland novel nor an Alice omnibus. Some of the original Alice illustrations by John Tenniel have been used as coverart for a great variety of later publications, beyond general Lewis Carroll collections and children's literature anthologies to NONFICTION works about children's book or fantasy, etc.
(to be augmented with a good exhibit or three) --Pwendt|talk 12:19, 24 May 2018 (EDT)

The Eugie Award?

Earlier today I came across The Eugie Foster Memorial Award for Short Fiction aka the "Eugie Award". Although this annual award (named after Eugie Foster) is presented at Dragon Con, it appears to be separate from the Dragon Award, which we already have on file. Many of the people involved are well-known figures in the field (Ellen Datlow, Mike Resnick, Neil Clarke, Sean Wallace, Sheila Williams), so it seems legitimate. Any objections to having it added as a new award type? Ahasuerus 17:07, 23 May 2018 (EDT)

Even Locus announces them. So I would say that we definitely should add them. Annie 17:36, 23 May 2018 (EDT)
Sounds good to me. ···日本穣 · 投稿 · Talk to Nihonjoe 18:20, 23 May 2018 (EDT)
Without objection, so ordered. Have at it!. Ahasuerus 17:33, 25 May 2018 (EDT)
And all 3 years of the award are now entered. Annie 04:00, 29 May 2018 (EDT)
Thanks! Ahasuerus 08:45, 29 May 2018 (EDT)

Technical difficulties: 2018-05-24

The server ran into certain technical difficulties earlier this morning. Everything should be back up now. Sorry about the inconvenience! Ahasuerus 10:05, 24 May 2018 (EDT)

Is this caused from the same thing that basically kept us down for most of the US night the previous day? (just curious) Annie 11:28, 24 May 2018 (EDT)
I was just going to ask that (for once I had a bit of time) :o) ! Linguist 11:31, 24 May 2018 (EDT).
I am not sure what the sequence of events was. The backups failed twice in a row, i.e. on Wednesday morning and then again on Thursday morning. I had to re-run then manually to ensure that we had a good backup. On the other hand, the server seemed to be fine between 10am and 11:30pm server (Eastern Daylight) time, which is when I approved my last edit. I'll check a few log files later today to see if I can figure out what the root cause of the problem was. Ahasuerus 11:43, 24 May 2018 (EDT)
It was down when I checked somewhere around 3 am Eastern time last night - it was still up at an hour earlier pm; it went down around the reports generation time the previous night - - 1:30 am or so (I actually wondered if the new report had something to do with it). Annie 12:04, 24 May 2018 (EDT)
It looks like you guess was right on target. It's cleanup report 237, which was added a few days ago. Although it runs fine on the development server, it goes into the never-never land on the main server. I will disable it until I can find a way to fix it. Ahasuerus 10:48, 25 May 2018 (EDT)
The new LCCN report has been disabled until we can find a way to get it to run on the main server. The cleanup reports will be re-run at 11:35am server time, which may close sluggish response times for 15-20 minutes. Ahasuerus 11:30, 25 May 2018 (EDT)
The cleanup reports have been successfully regenerated. Ahasuerus 11:48, 25 May 2018 (EDT)

Non-alphabetical Names in the Author Directory

At this time our Author Directory doesn't include names whose first or second letter is a digit, e.g. 1968 Mazan and 123rf. How about we add a new link below the main table and call it something like "Non-Alphabetical Names"? Ahasuerus 17:19, 25 May 2018 (EDT)

Works for me. ···日本穣 · 投稿 · Talk to Nihonjoe 17:59, 25 May 2018 (EDT)
Yep, as I said elsewhere, works for me :) Annie 18:04, 25 May 2018 (EDT)
FR 1154 has been created. Ahasuerus 14:13, 27 May 2018 (EDT)

Images for interior art

We allow (I'll stop short of saying encourage) the entry of interior art as part of a publications contents. However, unlike the cover art which has images, it is difficult to match up entries to variant them unless one owns both of the containing publications. Where the interior art is a specific image (e.g. a map, or titled illustration), would it make sense to upload an image to ISFDB and put the link in the title notes for the INTERIORART? This would allow for the merging or varianting of such entries. The fair-use purpose is to be able to match corresponding images. We could recommend a lower resolution than cover images. ../Doug H 23:36, 25 May 2018 (EDT)

Our title records have a field for third party Web pages. If we decide to start uploading scans of interior art to the ISFDB Wiki, we can enter Wiki URLs there.
That said, I am not sure what the legal ramifications would be. With cover art scans, we have legal precedents which are pretty solid. I don't know what the courts have said about making scans of interior art available on the Web.
I also recall a previous Wiki discussion of this issue, but it's been a few years and I don't remember the arguments (pro et contra.) Ahasuerus 15:41, 26 May 2018 (EDT)

Publications with direct Library of Congress/OCLC links in Notes changes request

Can we have "Ignore" option in the LCCN report. We are down to 4 titles and all 4 still have a link because the PV had copied data from the copyright page - and this data contains the link. Which means that we may be getting more of these in the future - and if it is on the copyright page, it belongs here :) And while we are on that, the OCLC one can also use an Ignore - the title on the very top contains a link to a search in WorldCat (and not an OCLC -these I pulled). I can edit and remove the reference but it is a valid usage of the link so I would rather leave it in place. Both can wait - although if we can get the LCCN one, that report will be all done and dusted :) Thanks! Annie 14:59, 26 May 2018 (EDT)

The LCCN report has been updated. Ignore away!
As far as the OCLC report goes, I'll fine-tune the report generation logic to look for "worldcat.org/oclc/" as opposed to "worldcat.org/". That should take care of search links.
As a general rule, I'd rather not add the "Ignore" functionality until we are down to a well-understood (and hopefully small) subset of records. We've dealt with quite a few accidental/invalid ignores and they are always a pain to find and correct. Ahasuerus 17:17, 26 May 2018 (EDT)
As long as we do not have 100 entries stuck at the top, the OCLC does not need the Ignore yet. I just mentioned it because we were on the topic :) And yes - fine tuning the search is probably a better first step :) Annie 17:25, 26 May 2018 (EDT)
Checking the last backup, I see that we had 43,106 direct OCLC links this morning. Of that number, 39,581 were "/oclc/" links and 3,525 were "/title/" links. Of the 21 remaining links, roughly half a dozen were typos, which have been corrected. The rest are "/search" links and I have modified the software to ignore them for now. At some point we may want to create a template for OCLC searches in case their search URLs change, but it's not urgent. I am sure we'll revisit this topic once the dust settles. Ahasuerus 17:46, 26 May 2018 (EDT)
I was just about to ask you for the OCLC numbers this morning. Thanks for tweaking the reports :) Annie 18:33, 26 May 2018 (EDT)
With this, the LCCN links are all cleaned and migrated. We still have the non-linked values (aka Phase II) but at least something got finished :) Annie 17:25, 26 May 2018 (EDT)
Very nice! Ahasuerus 17:46, 26 May 2018 (EDT)

Project: directory entries for Hungarian authors

Someone should go through the Hungarian authors and make sure that their directory entry is properly set to the surname. I've spotted and corrected some that were the wrong way around, but I don't know enough about Hungarian names to do it properly. --Vasha 03:28, 30 May 2018 (EDT)

It had been on my list of things to do now and then - they tend to be reversed a lot because of how they get printed (same with Japanese names). And a lot of them they will come in pairs actually - although I think I found most do these last year and pseudonymed them around. I’ll check through them again later this week. :) Annie 04:06, 30 May 2018 (EDT)
The directory names should be all sorted. I have some more work to do on the Hungarian authors but that part is done. If someone needs me, I am sorting out the Hungarian records and translations. :) Annie 16:57, 30 May 2018 (EDT)

"Publications with Invalid Prices"

This cleanup report has been updated to incorporate publications whose prices include the Euro sign followed by a space. The data, which includes approximately 1,640 publication records, will become available around 1:20am server time. Ahasuerus 18:11, 30 May 2018 (EDT)

If all that needs to be done is remove the space, is there a way to automate that? ···日本穣 · 投稿 · Talk to Nihonjoe 18:15, 30 May 2018 (EDT)
It's possible, but it won't guarantee that we won't have the same issue in the future while this cleanup report will always be available.
If 1,640 records are too labor intensive to fix manually, we can have moderators review them to ensure that there are no oddball cases and then run a conversion script. Ahasuerus 18:38, 30 May 2018 (EDT)
They are not unmanageable but they will be mind-numbingly boring and typos and bigger mistakes will happen. I'd say to go for option 2 - get the moderators to "clear" them visually over the next few days and clear the ones that have other issues and then run a script on the remaining. We can use this thread to coordinate which letters are being inspected/are inspected so we do not duplicate the effort.
Alternatively, as there are not too many issues that may happen, can you get the column from the DB for them so we can inspect this (as opposed to opening 1,640 of them, looking them over and closing - and missing something weird just because they do get into each other...Annie 19:56, 30 May 2018 (EDT)
The report as it is currently written displays each pub's price :-) Ahasuerus 21:06, 30 May 2018 (EDT)
Ah, I've forgotten that. Then it should be easy enough to clear them and let you run a script on top of them :) Annie 22:24, 30 May 2018 (EDT)
All clear - you can run a script that drops the space after € or replaces "€ " with "€" or whatever you feel like coding :) Annie 01:32, 31 May 2018 (EDT)
Thanks for checking! I have run a few spot checks to see if there may be other patterns that we could learn from -- verifiers, languages, etc -- but nothing obvious stands out.
I'll see what I can do on the automation side. The Euro sign is a bit tricky because it was added after the fact and different encodings handle it differently. Ahasuerus 08:56, 31 May 2018 (EDT)
A lot of German titles is the only pattern I saw - they were also what made me look for these - moving external identifiers can be fun this way. Mostly old titles though. And I’ve already fixed some before even asking you what we are checking for the other day. On the other hand, considering the main languages we have, German is the most likely anyway. Annie 09:20, 31 May 2018 (EDT)
Can’t you use the same logic that found them? Annie 13:08, 31 May 2018 (EDT)
Done. It wasn't hard, I just had to be careful not to mess things up. The way we handle non-ASCII characters is best described as "a band-aid on top of a band-aid", so you can't be too careful :-) Ahasuerus 15:14, 31 May 2018 (EDT)
It may also be useful to have any new entries cleaned automatically if there is a space between the currency symbol and the price. That should catch most of these in the future. ···日本穣 · 投稿 · Talk to Nihonjoe 13:30, 31 May 2018 (EDT)
Or the moderators can pay attention and work with the editors whenever there is a reoccurring pattern - as they are supposed to. :) We rarely see anything on that report because people do pay attention to the dollar sign. We had that many here because noons was looking for them for years.
I am not against automation but considering that this is a non-standard symbol, we may end up making more harm than good. Just saying. :) Annie 15:44, 31 May 2018 (EDT)
A warning either for the editor or on the approval screen may be a good idea though. Annie 15:55, 31 May 2018 (EDT)
It could be for any currency symbol, not just the Euro symbol. It should be fairly easy to have a list of currency symbols and have it remove spaces after any that shouldn't have a space. ···日本穣 · 投稿 · Talk to Nihonjoe 15:57, 31 May 2018 (EDT)
There are a lot of different price formats in the database, e.g.:
  • DM 7.80
  • 24,000 Lit
  • -/4 1/2
  • 70 000 zł
  • zł 29.99
  • Kč 9.00
We may want to wait until we add support for multiple prices (as per the Roadmap) which will necessitate a redesign of the way prices are entered and displayed. Ahasuerus 16:57, 31 May 2018 (EDT)
Sounds like a good idea. ···日本穣 · 投稿 · Talk to Nihonjoe 17:24, 31 May 2018 (EDT)

"Authors with invalid Directory Entries"

The cleanup report "Authors with invalid Directory Entries" has been updated as follows:

  • The new compilation logic looks for authors whose Directory Name field contains non-English characters
  • The new logic no longer includes authors whose Directory Entry field contains numbers or punctuation
  • The report has been made available to non-moderators
  • The report no longer supports the ability to "Ignore" authors

Once the data is regenerated overnight, the report should contain approximately 2,840 author names. Ahasuerus 18:25, 31 May 2018 (EDT)

I am not sure that accents are a problem - I had been fixing a lot of authors starting with "Bé" and it keeps saying "count 2958 for section [Be]" (number remains the same) - it moves when it is a non-accent special character. On the other hand it does recognize them as different so it is better to clean them despite the software seeming to not mind them much for this - who knows what happens elsewhere. Annie 19:14, 2 June 2018 (EDT)
It so happens that the "section [Be]" stuff was deprecated a few years ago :-) The table is still kept up-to-date, but its data is no longer used by the system. I plan to remove it when I have some free time. Ahasuerus 19:35, 2 June 2018 (EDT)
It is a useful indicator that the first 2 letters had been changed though (and it does count properly outside of these accent thingies) - but good to know. Back to editing authors :) Annie 19:37, 2 June 2018 (EDT)

(unindent) OK. These are taken care of but we have a few more corner cases: D for example. There is no place for this author in the Author's directory :( Annie 01:44, 6 June 2018 (EDT)

Good catch. I have updated FR 1154 to be more inclusive. Ahasuerus 09:24, 6 June 2018 (EDT)

LCCN report resurrected

As avid readers of this page know, the latest LCCN cleanup report was a fiasco. It crashed the database engine when it tried to run and had to be disabled.

I am happy to report that it has been resurrected and should generate new data overnight. The algorithm has been tweaked to identify pubs with notes that include "LCCN:" or "LCCN [digit]". The report has been renamed accordingly. The new and improved version lets moderators "ignore" pubs.

There are roughly 3,500 affected publication records, so the report is currently limited to the first 500 matches. Ahasuerus 18:31, 1 June 2018 (EDT)

Just on time for the weekend. Thanks! Annie 20:11, 1 June 2018 (EDT)
I think that there is a bug in the (first 500) when ignores are allowed. Before today's regeneration, the report was clean and the numbers was saying (500)(273 (I think)) - which meant that I had ignore 227 titles (sounds about right) and 273 were cleaned the regular way. After the regeneration, it shows me only 274 titles (and the numbers show (500)(274)). It looks like the first 500 are selected before the ignores are taken into account. Which will become a problem in a couple of days when I keep ignoring. :) I will leave that report alone tonight so you can see it. Annie 03:07, 4 June 2018 (EDT)
Investigating... Ahasuerus 10:47, 4 June 2018 (EDT)
It was the first "(500)" report to support the ability to "ignore" records. As you surmised, the processing logic didn't handle this combination of conditions correctly. I ended up lifting the 500 limit for this report; it should no longer be a problem once the nightly process runs. As of this morning we have less than 3,000 affected pubs, which should be manageable without the limit. Please feel free to process what's currently displayed! Ahasuerus 15:04, 4 June 2018 (EDT)
I was not sure how we handle the ignores (separate table?) but figured that something like that is going on. This report is very similar to the Amazon links one - a lot of false alerts (here because we are not filtering for the external ID; in the amazon links one because we also catch the archive.org links). I agree, 3000 is manageable. Thanks! :) Annie 15:14, 4 June 2018 (EDT)

Author biblios - near-identical author names are no longer confused

The other day Annie came across a bug in the software that drives author biblio pages. Near-identical author names like Ed Acuna and Ed Acuña could be confused with one substituting for the other. I ended up rewriting that part of the software (to make it better, stronger, faster!), which fixed the bug and, as a side effect, made the process of loading Summary pages a little bit faster.

As always, if you encounter anything unusual, please report your findings here. Ahasuerus 17:58, 3 June 2018 (EDT)

SFF Net URLs

As some of you may recall, SFF.net closed down in 2017, but we still have 100+ links to that domain. Looking for volunteers to identify all defunct SFF.net URLs using Advanced Author Search and replace them with Archive.org links (if available.) Ahasuerus 00:14, 4 June 2018 (EDT)

Some of them are already done, I will see what I can do for the rest over the next few days. Annie 18:13, 4 June 2018 (EDT)
Thanks! Ahasuerus 18:16, 4 June 2018 (EDT)
I think that someone else was either fixing them alongside me or someone had done that before - the whole second page was already done :). All are done now - except for a handful, they were salvageable from the Way Back Machine even though a lot of them had to go really back in time. From the problematic ones - most had forwarders put at one point and for others google found a new link. Annie 21:51, 4 June 2018 (EDT)
Excellent! I have changed the 3 SFF.net URLs used by our title records, so we should be all set. Well, almost -- we have another 5 title records with "sff.net" in Notes. I will get to them tomorrow unless someone else beats me to it. Ahasuerus 22:11, 4 June 2018 (EDT)
Got them. 4 are replaced with archive.org links; 1 with the new author's site page. All done now :) Annie 22:25, 4 June 2018 (EDT)
After re-checking all URLs and Notes I was about to close SR 115, but then I re-read the comments section of the SR and remembered that we still had a dozen SFF.net e-mail addresses on file. Sorry, this should be last chapter! Ahasuerus 22:41, 4 June 2018 (EDT)
While finding other mails may be possible, it will be too work intensive and quite unneeded in my opinion. So I think we should just delete them and be done with them. What do you think? Annie 22:56, 4 June 2018 (EDT)
<click-click-click> All right, one SFF.net e-mail address has been replaced with a new one, the rest have been deleted. The SR has been closed. Victory! :-) Ahasuerus 23:20, 4 June 2018 (EDT)
I had been working on this with a search. Uzume 15:16, 9 June 2018 (EDT)

Redesigning prices

Roadmap 2017 says:

  • Support multiple prices per publication

A year ago we had an extensive discussion of the desired software behavior. More recently, we tweaked the cleanup report responsible for prices to look for extra spaces between the currency symbol and the price.

I have been thinking about these issues for the last few weeks and here are my preliminary thoughts re: where we want to end up:

  1. Each publication record should allow an unlimited number of prices. This will be accomplished by converting the "Price" field to a "multi-field", which will use the standard "+" mechanism for adding additional prices.
  2. Within editing forms, each price row will contain two sub-fields per price: "currency symbol" and "price value". The look-and-feel will be similar to that of the "External ID" multi-field, which also contains two sub-fields (External ID type and External ID value) per row.
  3. Within each publication, prices should be displayed in "priority order". For example, a UK book which has one price for the UK, another price for Australia and a third price for New Zealand should display the UK price first. Note that this is different from the behavior of other "multi-fields", e.g. the order of authors within publications/titles is not enforced while external IDs are displayed alphabetically.
  4. Each displayed price should contain three components:
    • The price value, e.g. "24.00", "60,000" or "2/6"
    • The currency symbol, e.g. "£", "€", "$", "¥", "Kč" or "FF". The currency symbol should be displayed before or after the price value depending on the currency. Some symbols should be adjacent to the price value while other symbols should be separated with a space. Some currencies, like the old UK currency and "other", will have an empty displayed currency symbol. There will be a drop-down list of supported currency symbols similar to the drop-down lists of supported formats, external IDs, etc. The drop-down list will include additional information to facilitate the data entry process, e.g. "C$ - Canadian dollars" or "A$ - Australian dollars".
    • Currency-specific text displayed as a mouse-over bubble, similar to the way we display mouse-over information for publication formats. It will contain information about the currency, including the countries where it is/was used and any applicable ISO-4217 codes (some currencies have had multiple ISO-4217 codes and some older ones have none.) It will also be used to explain the formatting of obscure and unusual currencies like the old UK system.
  5. Prices whose currency is not in the drop-down list of supported currency symbols will be entered as follows:
    • The editor will select "other" in the list of currency symbols
    • The editor will enter the currency symbol and the price in the "price value" field
    • Once a critical mass of publications with the same unsupported currency has been reached, the currency will be added to the list of supported currencies, at which point the currency symbol will be moved from the "price value" field to the "currency symbol" field in the affected publications.
  6. Common currencies will be converted to the new design automatically. There will be one or more cleanup reports to handle uncommon currencies, typos, etc. There will be additional cleanup reports to find publications with price information in Notes.

I also have a preliminary design of the underlying database tables needed to support these requirements/design, but it's probably too technical to post here.

So, what do you think? Ahasuerus 12:32, 4 June 2018 (EDT)

General Discussion

Sounds usable and readable. What'll be the guidelines for which currencies to enter--for example, only ones that are on the book cover and/or publisher's website? What are acceptable data sources? --Vasha 12:44, 4 June 2018 (EDT)

I don't think the proposed redesign will require changes to the "acceptable data sources" part of our data entry rules, will it? Ahasuerus 13:50, 4 June 2018 (EDT)

I like the idea a lot :) A few questions/proposals:

How will the priority be determined? During the edit/add of publication? Based on publisher? Something in between? Annie 14:09, 4 June 2018 (EDT)
In most cases you can tell by looking at the book. For example, the cover of this pub says "U.S. $4.95 (Canada $5.95)", which tells us that the US price should be displayed first. UK-published books tend to start the price "block" with the UK price, e.g. "UK 35p, Australia $1.10; New Zealand $0.85; Malta 40c; Canada $1.35". If the ordering -- as presented within the book -- is ambiguous, then the way we order it within the database is probably not terribly important either. Ahasuerus 16:02, 4 June 2018 (EDT)
When you work from a book in hand, it is clear. But a lot of our records are either from secondary sources or by new/inexperienced editors and in such cases someone somewhere needs to make a decision. I guess common sense will need to be applied for now :) Annie 16:17, 4 June 2018 (EDT)
Hoping this (buried) comment doesn't get missed: Your example of US (Canada) is misleading - the cover is often identical for US and Canadian printings, because the cover is printed in the US, but the book will be printed in Canada. The only way to tell is to check the printing location on the copyright page. See this US and this Canadian as examples. Doesn't invalidate the solution, just the conversion. ../Doug H 08:57, 5 June 2018 (EDT)
Thanks for the clarification! Ahasuerus 09:06, 5 June 2018 (EDT)
Can we have a statistics page coded at the same time that gives the split of publications per priority currency (similar to the one we have for title language for example) and per currency at all (for example we won't have a lot of prices in Maltese or Austrian currency as a priority one but a lot of the European ones are coded for one or both of those as additional price as well? Annie 14:09, 4 June 2018 (EDT)
I am sure we will want something like that, although I can't promise that it will happen as part of the original rollout. Ahasuerus 17:42, 4 June 2018 (EDT)
When this is implemented, it may be a good idea to start keeping a table in the help pages with all the currency we already know about per country (so that a new editor does not wonder how to record something new - like the Spanish peseta or the French franc that are now recorded in multiple ways) Annie 14:09, 4 June 2018 (EDT)
I expect that some of this information will be made available in the "currency symbol" drop-down list, but it's entirely possible that some of it will have to be spun off as a Help page. Ahasuerus 17:45, 4 June 2018 (EDT)
Yes, for the ones that make it in the "Currency symbol" drop-down. I am thinking about the ones that do not and need to be frre-styled - we cannot count how many Lev are there if people use BGN, BGL, Lev, Levs, Lv., Leva and Lv interchangeably. And even if the regular editors know, a moderator/editor that does not work in the language should have an easy way to find the correct currency abbreviation/symbol.  :)Annie 17:55, 4 June 2018 (EDT)

Multiple Prices in the Same Currency

One corner case to think of is the double prices in the same currency (the devaluation of currency had happened in more than one country) - for example Bulgarian books carried two prices for awhile, both being lev (unlike some other countries that added old/new to one of the two states, we just kept on rolling with the same name (different ISO codes though (BGL vs BGN) - we just lost 3 zeroes) - and then there are 2 earlier iteration of the same process (with double prices again but no ISO codes to differentiate). We need the ability to record both but give priority to one of them. It sounds like the design will handle that but just throwing it in. Annie 14:09, 4 June 2018 (EDT)

Something vaguely similar happened in the UK during the "decimalisation" reform in 1971. Some books had stickers with new, decimal, prices on top of the original pre-decimal prices. However, I am not aware of any books that had two sets of prices printed on the covers.
The Bulgarian denomination appears to be closer to the most recent Russian denomination (1998) when the banknotes lost 3 zeroes and the ISO code was changed. Luckily, as we discovered a few years ago, Russian books didn't have list prices at the time, so there was nothing for us to record. Was it different in Bulgaria? If it was, then we may need to record two prices per pub, which should be supported by the proposed design. Mouse-over Help for the lev will need to explain what's going on. Ahasuerus 17:14, 4 June 2018 (EDT)
Bulgarian books had both prices printed on both the back cover and the copyright pages for a few months - allowing the book to be sold before and after the change easily. Not all publishers did it but a few did (and they publish in our genres - I guess they wanted to be ready for the change) and it did not last long but there was definitely a period of a few months when that was the reality. We can use just notes for that if need be but just wanted to point out the case. I've asked someone that has access to their books to verify again that my memory about the back covers is not faulty (just in case) but I do remember these double prices. Annie 17:45, 4 June 2018 (EDT)
A friend did a spot check last night and it seems like my memories of this being a common practice are a bit foggy (it had been awhile). Most of the ones I was thinking of had a single price on them although a few non-genre ones had both. So that may be less of a problem than I thought it will be. On the other hand, apparently these days they add the euro price on a lot of books (which won't be a problem but it is still funny). Annie 14:16, 5 June 2018 (EDT)
This also raises another question: what do we do when e-prices change? Normally, we record the list price and ignore any discounted prices used by Amazon and other online stores. (Sometimes I record the Kindle price at publication time if it's drastically different from the list price, but I do it in Notes, which is a free-for-all area.) Lately, however, I have been seeing cases where the original list e-price was reset by the publisher when something happened. In most cases the trigger event seems to be the appearance of another edition of the same book. For example, suppose a book was first released as a hardcover ($26.99) and as an ebook ($14.99.) 12 months later a mass market version of the book is released ($7.99) and the list price of the ebook edition is lowered to $6.99. At the moment we pretty much ignore all post hoc list price changes, but we may have to reconsider if this becomes more common. Ahasuerus 17:14, 4 June 2018 (EDT)
We have a secondary problem here as well - ebooks get updated and we already have some pairs in the DB (v 1.04 and v1.05 for example). And then there are books only available only in some markets... Annie 14:16, 5 June 2018 (EDT)

Price-specific Notes

One more thing that I do not think the design covers - sometimes we may have two separate prices in the same currency but meant for different countries. Example: this publication. It has two Euro prices for 2 different countries. Just adding the two prices will be losing data - we need to be able to add the country to the price. That will come up a lot when we have common currencies in multiple countries. Annie 14:16, 5 June 2018 (EDT)

The proposed "price value" sub-field will allow arbitrary text, so I guess we could simply enter:
  • Price 1: "€" in the "currency symbol" sub-field; "24.99 (Germany)" in the "price value" sub-field
  • Price 2: "€" in the "currency symbol" sub-field; "25.70 (Austria)" in the "price value" sub-field
Ahasuerus 14:44, 5 June 2018 (EDT)
While that may work in theory, that will open the door for all kinds of non-standard inputs AND searching will become a nightmare (how do I find all books that cost €4.99 (we are a DB, this is a basic query)? If we decide to go that route, we need to be careful about formatting (and then what happens with books that have only one price - do you tag it for the country or not? I'd much rather see a third field that gets populated based on the currency symbol (or even just a simple "comments/additional details" field on the same level where you can add the country name or any other note (old/new price for the Bulgarian books above for example).
This way you have the currency in one field, the price in another (which now can be validated to be a number and so on) and then any other notes in a third one - empty for most prices; useful for the ones that have some notes to be added. Annie 14:55, 5 June 2018 (EDT)
An interesting point. Conceptually I agree that we should try to define our data elements in a way that mimics the real world, which, in this case, would mean having a separate sub-field for notes.
I actually considered having a third sub-field for notes early in the design process, but then I was swayed by the fact that the original conversion process would result in a lot of unstructured data left in the "price value" field. That shouldn't be a significant factor, though, because we'll have a manual post-conversion cleanup/review process, which will give us an opportunity to move typo'd currency symbols and "free text" notes to the right sub-field. Ahasuerus 15:26, 5 June 2018 (EDT)
Then we clean them up properly later on - pull everything up to the the numbers (plus dots and commas) only in the middle field during the automated conversion, dump the rest in the third field and then we can clean/move based on that. This way you actually have a better way to clean because the "10 din." will end up with ("no currency symbol", "10", "din.") - which then can have a second automated process that gets predefined strings (once we see the results, patterns will emerge) from the third field and converts them properly into the second (we have a lot of "din" ones for example.
I still think that the 3 fields approach is not just cleaner but also will make the migration easier.
Or we can even start thinking a bit differently - leave the middle field for the price only (always). Then the currency either goes in the third field or we do some UI magic to show it first. Then during the conversion, we can leave just the numbers in the field anyway and the third field will collect "Lv" from both "Lv 10" and "10 Lv" for example. Annie 15:44, 5 June 2018 (EDT)
I am sorry, I may not have been clear. I was saying that I was tentatively inclined to agree with the addition of a third sub-field for price-specific notes. I was simply explaining why I had decided against it early on. Ahasuerus 15:55, 5 June 2018 (EDT)
Ah, ok. Sorry - I think I was just on a roll and kept typing :) I was mostly thinking with my fingers about what I had seen in some of the international publications (and of what kind of cleanup they will require). Annie 16:04, 5 June 2018 (EDT)

Timeline

Do you have any timeline for this change (if there aren't too many objections)? I am hitting the DNB IDs hard these days and we have a lot of "other prices" there so if this is coming, I can leave them alone for a bit and then get them cleaned up when I can also pull the prices out :) Annie 14:09, 4 June 2018 (EDT)

My monthly routine consists of three components:
  • Fixer and other regular maintenance (weekly/monthly backups, e-mail, performance, etc)
  • Bug fixes and minor FRs requested on the Community Portal
  • Roadmap 2017 implementation
At the moment, my Roadmap priorities are:
  • Support multiple ISBNs per publication (still needs final design tweaks)
  • Create a history of changes to primary-verified publications by storing a snapshot of the way each verified pub looked like right before it was changed
  • Support multiple prices per publication (once the design has been finalized)
I can do these three in any order, so it's up to vox populi. However, something else has come up recently, namely security enhancements, and I need to work on them first. I just wanted to post the proposed redesign here so that we could all discuss it while I am working on security. Ahasuerus 16:13, 4 June 2018 (EDT)
Ok then. Have fun with the security changes :) Annie 16:17, 4 June 2018 (EDT)

Publishers and Imprints

PS: Does the multiple ISBNs also mean multiple publishers or do we track the two separately? Annie 16:17, 4 June 2018 (EDT)

Multiple publishers (and imprints!) are a whole different can of worms. Big juicy worms too... Ahasuerus 16:38, 4 June 2018 (EDT)
I'd argue that multiple publishers (two separate publishers being printed on the title page and considered the publisher of the book) (as in the Russian editions of way too many books or the first (and some later) books in this Bulgarian series is a very different problem from the imprints one (and their cannibalization, selling, reselling, merging, splitting (now I need a dictionary to find more words...)). They may be falling under the same umbrella of "fix the way we handle publishers" but they are different and can be tackles separately. Annie 17:08, 4 June 2018 (EDT)
There are certain issues with imprints which make it hard to separate them from publishers. The first one is the fact that:
  • some imprints get spun off and become publishers
  • some publishers get purchased by larger companies and become imprints
In addition, there are complex multi-level publishing pyramids which make it hard to distinguish publishers from imprints -- see this picture. Also, back when we were looking into Russian publishers, we discovered that in many cases what we thought were "co-published" books had been published by one publisher which had spun off some of its departments/imprints as semi-independent companies for some (legal? tax?) reason.
Finally, some books include both the name of the publisher (and/or its parent companies) as well as the name of the imprint. OTOH, certain other books include the name of the imprint and nothing else. A "naive" editor will have no way of telling whether there is more to the stated imprint and will enter it as the name of the book's publisher. And, of course, sometimes publishers print slightly different versions of their name in their books, which may or may not be significant.
Ideally, our ultimate solution should account for all of these permutations. Perhaps we could borrow the concept of "variants" and "pseudonyms" from other parts of our software: capture the data as it is printed in the book and then variant it to the publisher's "canonical name".
It will probably take a fair amount of work to come up with a comprehensive solution. Ahasuerus 17:39, 4 June 2018 (EDT)

But yeah, it is not the same as the ISBNs ones (hope and so on :) ). And then we have the Translators as well... Annie 17:08, 4 June 2018 (EDT)

Tentative Outcome

FR 1158 has been created. It incorporates Annie's proposed separation of "price value" and "price comment". Ahasuerus 12:40, 11 June 2018 (EDT)

I won't comment on the outcome of this "discussion" (between two persons) as I've other things to do than to discuss something that is already decided or where the possible input of some is simply ignored. Hauck 14:22, 11 June 2018 (EDT)
Are you referring to your proposal that we should use the "XXX<space>888.88" format "where XXX is the ISO code" for displayed currency designations? If so, then the issue of ISO codes is addressed in the proposal language where it says:
  • Currency-specific text displayed as a mouse-over bubble, similar to the way we display mouse-over information for publication formats. It will contain information about the currency, including the countries where it is/was used and any applicable ISO-4217 codes (some currencies have had multiple ISO-4217 codes and some older ones have none.)
Based on the discussion that followed and the issues with ISO-4217 that are mentioned in parentheses above, it was the best way to incorporate this information into the database that I could think of. Ahasuerus 15:17, 11 June 2018 (EDT)
Just for the record "FF" is not a symbol and is simply not used in France (as logically we talk about "Francs" and not "French Francs").Hauck 14:22, 11 June 2018 (EDT)
One of the advantages of the proposed approach is that all currency symbols (perhaps a more generic term like "currency designations" might be better) would be table-driven. If and when we were to decide to change a currency designation, we would need to alter a single value in the database, e.g. "F" to "Fr" or to "FRF", instead of having to find and convert thousands of prices manually. Ahasuerus 14:58, 11 June 2018 (EDT)
One thing I do not see in the proposed design - the price also needs to be optional. Think of publications like this one or the Australian ones. You want to specify the currency (so it is searchable for it and obvious that it is an Australian edition) but you do not know the value. Annie 17:05, 11 June 2018 (EDT)
Good point. I have clarified that "blank values are allowed if we know the currency, but not the price." Ahasuerus 17:29, 11 June 2018 (EDT)

Currency Symbol vs. Currency Designation

Based on the discussion above, I'd like to propose that we change the name of the envisioned table-driven currency sub-field from "currency symbol" to "currency designation" since the latter covers a wider range of scenarios. Can anyone think of a better term? Ahasuerus 15:24, 11 June 2018 (EDT)

Why not just "currency"? We can use a symbol, a short form, a complete name - whatever makes sense for that specific currency - it still is the currency. Annie 16:43, 11 June 2018 (EDT)
Sure, we can do that too. If we were to further simplify, the names of the three sub-fields would be:
  • Currency [drop-down list]
  • Value
  • Comment
Ahasuerus 17:26, 11 June 2018 (EDT)

Price as stated

After re-reading the discussion that we had last year, I'd like to discuss one suggestion that was not incorporated in the design outlined above:

  • ... one thing that has always troubled me about the price field is that in many cases it doesn't reflect what's printed on the item but attempts to translate it into a standard, but the standard is rather loose and has perhaps more exceptions than actual rules.
  • In my dream database there's a field where you can record each price directly as it's listed on the pub, then a separate field (or fields) where you can enter a proper amount and identify the currency for sorting and comparison purposes... Albinoflea 23:17, 3 July 2017 (EDT)
    • I agree with this idea. I work in a world of compiling information from disparate sources where there is no uniform reporting standard, and we have found it best to capture and preserve as-reported and to maintain normalized/computed separately. --MartyD 09:26, 4 July 2017 (EDT)

Here are some of the more common scenarios that I have encountered:

  1. One or more list prices (including the currency designation) are explicitly stated in the publication.
  2. A price value is stated, but the currency is not specified, typically because it is assumed to be the currency of the country where the book was published.
  3. A price may have been stated, but the verification copy doesn't have it, typically because the dust jack is not available.
  4. There is no price present, so we have to use a secondary source (or sources) to determine what it was. Things can get complicated, especially when dealing with e-books.

Does this list match other editors' experience? If so, then I can see how having a separate field for "price(s) as stated in the publication" would be beneficial when dealing with Scenario 2. When dealing with Scenario 1, the additional information would be duplicative. Under scenarios 3 and 4, we would pretty much have to record what we have been able to discover in Notes.

Given these scenarios, I am not sure the advantages of having the proposed field would outweigh the costs associated with the extra complexity and data duplication. Are there additional considerations or scenarios that I am missing? Ahasuerus 16:31, 11 June 2018 (EDT)

I like that idea a lot actually. Even if there is duplication, it will have the "data as on the book" which I find very appealing. Maybe as a totally new field (and not as a comment next to each price) - because if it says "$10.99/CAN10.99", you want 2 separate prices but you want the exact price information in one field, supporting new lines (br or \n). (I think - I can also see it on each price individually). Of course we can just use the notes for it but having a separate field have the advantage of being searchable on its own and for people to remember to collect that information. Annie 16:54, 11 June 2018 (EDT)
Well, if we were to capture the price data "as stated" verbatim, including new lines, then, as you said, it would become a new "notes" field at the publication level. We would be effectively splitting the current Note field into two: "Price Notes" for price information and regular "Notes" for everything else.
From the technical perspective, it would be doable, but would our users find this separation helpful? Also, if we were to go down that path, are there other field-specific parts of Notes that we would want to put into separate Note fields? Ahasuerus 10:24, 12 June 2018 (EDT)
I've been thinking about this conversation this morning - and wonder if we are not treating the Price as a special component when it is not. Our current notes field contain 2 different types of information:
  • Information from the book as is (copyright page, title page, covers, pages, differences in page numbers between TOC and stories and so on (only ob PV'd books)
  • Information from other sources: dates notes (that the date is from Amazon and/or from another source or from publisher's site), data from secondary sources and differences between them and what we have, connection to other books (covers credit based on that and so on)
Depending on the editor style, these may be easily recognizable or it may be a bit of a head-scratcher to figure out what is from the book and what is from OCLC/DNB/Amazon/you name it. So I was thinking that if we are going to split the Notes field, that is the more logical line for a split than getting separate fields per element (if we are keeping as is that is).
I know that the 600K or so publications that we have (I know we are closer to 700K in the IDs but we also have a lot of deletions so I am estimating) Annie 13:41, 12 June 2018 (EDT)
According to the "ISFDB Statistics" page, we have 505,922 publications. 145,024 of them have been verified. Ahasuerus 13:56, 12 June 2018 (EDT)
OK, apparently I need more coffee because I forgot we have this specific statistics page. Thanks for the correction :) Annie 14:18, 12 June 2018 (EDT)
don't have the split and it is almost impossible to make it retro-actively but... they can be marked as "unsplit" or something so it is clear that they are not and we could split going forward.
I am not sure how useful that will be but I personally would love that (and yes, that means that for non-English books, the "as is" Notes will be in the foreign language. Which is fine for me. An editor can provide a translation in the other field. I know that we are an English - language DB but as is does not exist just for the books that happen to be in English. Annie 13:41, 12 June 2018 (EDT)
I agree that it's useful to distinguish between what's stated in the book and what we derived from secondary sources. However, in many cases primary and secondary information overlap, e.g. "Publication date not stated, taken from OCLC 123456" or "Price not stated, taken from the SFCB catalog". I suspect that splitting it and making it available in two separate Notes fields would make it harder to digest. Ahasuerus 20:48, 12 June 2018 (EDT)
Both of these will stay in the "not as-is" field though... And the as-is won't be a mandatory field (notes are not either so... no problem) - it will be for editors that want to record as is, for data like this (so it get archived with the record and not as part of the wiki only) for example and so on. For some series, it may be important to record the editors from a copyright pages, for some languages, it may be the exact spelling of some data... and for some, it will be the price as stated. Or for the exact spelling of the author names and titles. I may be overthinking it but at the moment all is a big jumble of quotes, foreign language text (with translation I will admit) (the German book's edition information for example), lists, paragraphs and what's not. Trying to figure out how was Kelly credited on some books when I was switching the canonical was like pulling teeth - not because our editors do not record the information but because everyone has their own style and some of them using the same style meant diffent things ("Kelly credited on the copyright page" for example).
As I said - I was just thinking about the price "As is" field this morning and wondered if we should not look at the whole thing from a different angle... Annie 21:13, 12 June 2018 (EDT)
I see. I think I understand where you are coming from, but I am not sure creating a new Notes field for our "as is" data would be the best way to address the need. Perhaps it would be best to sleep on it and then start a separate discussion section to see if we could come up with more specific requirements that would ultimately lead to choosing a design. Other editors may be more likely to chime in if the discussion is "fresh". Ahasuerus 23:35, 12 June 2018 (EDT)
Absolutely. Have a good night :) Annie 00:16, 13 June 2018 (EDT)

Authors without a Working Language

When you have a chance, can you throw in another letter in Authors without a Working Language (or convert to first 500 or something else like that)? A few people had been steadily working on the list in the last months and we need some new blood in that report while dealing with the remaining ones there... :) Thanks! Annie 16:22, 4 June 2018 (EDT)

OK, the letter "W" has been added. The data -- approximately 3,900 author records -- will become available tomorrow morning. Ahasuerus 18:06, 4 June 2018 (EDT)

Security changes - step 1

As previously indicated, I am currently working on security enhancements. I am about to install the first patch in what I expect to be a series of patches.

The annoying thing about security enhancements is that most changes do not have any visible benefits and sometimes break unrelated things. Hopefully, nothing significant will be broken in our case, but if you seen anything unusual, please post your findings here. Ahasuerus 18:32, 5 June 2018 (EDT)

The first patch has been installed. Ahasuerus 18:34, 5 June 2018 (EDT)
Patch 2 has been installed. It affected the way all of our data editing forms are submitted. If your browser experiences issues creating submissions, please post the details here. Ahasuerus 13:26, 6 June 2018 (EDT)
Patch 3 has been installed. There shouldn't be any user-experienced changes. Ahasuerus 20:38, 7 June 2018 (EDT)
Patch 4 has been installed. From this point on we can assume that all security patches are supposed to have no effect on the end user experience unless explicitly noted. Ahasuerus 15:30, 8 June 2018 (EDT)
Patch 5 has been installed. It tweaked the way our software determines which field to put the cursor on when Web pages is loaded. There should be no user-experienced changes, but you may need to force a full page reload (Control-F5 in most browsers) in order to sync everything. Ahasuerus 14:34, 9 June 2018 (EDT)
Patch 6 has been installed. It cleaned up after the previous patch and also made some changes to the way Edit Award and Add Award are handled behind the scenes. If you see anything unusual and Control-F5 doesn't fix it, please post your findings here. Ahasuerus 18:55, 9 June 2018 (EDT)
Patch 7 has been installed. It changed the way pop-up validation works behind the scenes, but there should be no user-experienced changes. As always, if you see anything unusual and Control-F5 doesn't fix it, please post your findings here. Ahasuerus 20:12, 11 June 2018 (EDT)
Patch 8 has been installed. There should be no user-experienced changes, but you will definitely need to do a full page reload (usually Control-F5) for everything to work correctly. Ahasuerus 12:35, 13 June 2018 (EDT)
Path 9 has been installed. It changed the way External IDs are handled behind the scenes. The only user-experienced difference is that the question mark icon and the associated mouseover help are now limited to the first displayed external ID. Ahasuerus 16:13, 14 June 2018 (EDT)
Patch 10 has been installed. It finalized the External ID changes which were started in the previous patch. You will definitely want to do a full page reload (Control-F5 in most browsers) before using the "+" sign to add External IDs. Ahasuerus 18:51, 14 June 2018 (EDT)

(unindent) Path 11 has been installed. It changed the way Advanced Search works behind the scene. There should be no user-experienced changes. You will want to do a full page reload (Control-F5 in most browsers) the first time you use Advanced Search. Ahasuerus 10:26, 15 June 2018 (EDT)

Baron de La Motte Fouqué surname?

What is the "principal" surname of Baron Friedrich de La Motte Fouqué? He has a huge number of variants of his name in the database, and they aren't all set to the same directory entry. He is usually referred to as "Fouqué" in English. In the DNB he is "Fouqué, Friedrich de La Motte," and in Neue Deutsche Biographie he is "Fouqué, Friedrich." Would it be OK to set the directory entry of all his variants to "Fouque"? --Vasha 17:09, 6 June 2018 (EDT)

Pseudonyms do not need to have the same directory entry - if anything, they are supposed to be different for different spellings to enable the finding of the authors.
Look at them a bit more carefully. Directory name is not the same as "common name" or "most common name". It is "the last name as written in that variant with the special characters taken care of". On a quick glance, this variant and this one can never get the directory entry as Fouque (they were missing its "-" because of an older policy on special characters but for that spelling, the directory name is "Motte-Fouque". And this one is a totally different cattle of fish as well.
Now if you are asking if the ones without the hyphen should be Fouque or "Motte Fouque", that's a legitimate question. I personally look for that author under "M"... but that's just me :) Annie 17:24, 6 June 2018 (EDT)
Why M? If he was French it would be "La Motte." We need a German speaker to decide what the directory entry for all those variants is. Or for the ones that are English language publications, the library of congess uses "La Motte-Fouqué, Friedrich Heinrich Karl, Freiherr de." (and says, Fouqué, Friedrich Heinrich Karl, Freiherr de La Motte, see La Motte-Fouqué).--Vasha 17:36, 6 June 2018 (EDT)
Because this is where I had seen him shelved - not that it could not have been wrong (or weird - I just shared where *I* would look for it). People can still share opinions, right? As I said - it is a legitimate question but not for all the pseudomyms - the 3 I listed above cannot have just Fouque because of their spelling. Annie 17:46, 6 June 2018 (EDT)
No, it is not a weird opinion at all. Just a non-English one. But should we go with La Motte as the directory entry for English language publications where possible? The British Library also shelves him under "La Motte." --Vasha 17:51, 6 June 2018 (EDT)
Sorry but I am going to reject all of your attempts to edits on this until at least someone else agrees/disagrees. Give it a few days, hopefully a few more people will chime in. You cannot start a discussion, give it under 36 hours and just do what you wanted to do anyway. A little patience please - give it at least a few days (including at least the weekend) - not everyone lives in ISFDB 24/7. Annie 01:03, 8 June 2018 (EDT)
A difficult case, but DNB as well as my general encyclopedia file him under F (for Fouqué), so it seems that is the canonical surname for him, at least for the German language. Stonecreek 04:09, 8 June 2018 (EDT)
If I may introduce my own Lumbricus terrestris into this can of worms (and a reheated one, IIRC), the Library of Congress entry as "La Motte-Fouqué, Friedrich Heinrich Karl, Freiherr de" seems to me the correct one, as it complies with the Gallic way of treating French proper names containing the nobility particle de which is never taken into account as far as classification is concerned (and never has a capital D) : Jean de La Fontaine appears under “L”, Alfred de Musset under “M”, etc. That the good baron was German doesn't change the fact that the place-name following de starts with an L (La Motte-Fouqué, originally La Motte-Fouquet in Normandy) which does take the capital. This to say that I am all for a La Motte-Fouqué entry. Linguist 11:36, 10 June 2018 (EDT).

(unindent) Yes, it's clear enough that the English-language practice is to file him under "La Motte" a.k.a. Lamotte a.k.a. La Motte-Fouqué and it seems (I think?) that we ought to use those forms with "La" as the directory entry for any variant that only has publications in English. But the German practice is to file him under Fouqué: as well as the two sources I cited above, the De Gruyter Deutsche Biographische Enzyklopädie has "Fouqué, Friedrich (Heinrich Karl);" Zeno.org has "Fouqué, Friedrich de la Motte;" etc. etc. So what does that mean for us? Any variant of his name that has only German publications should use the directory entry Fouqué; but what should we do about any that has a mix of German and English publications, and about his main record? --Vasha 15:46, 10 June 2018 (EDT)

As far as I know, this db mostly follows the English usage, and the main record should be under La Motte-Fouqué. I don't really see the problem, since all pseudos will lead to it. As for the German usage, it is just not coherent with the history of the name, period. Anyway, it is our decision. Linguist 16:03, 10 June 2018 (EDT).

Possible Software Solution

Let me put my software designer cap on for a minute.

One thing that we have discovered over the last few years is that the old expression "When you come to a fork in the road, take it" is pretty good advice when deciding how the ISFDB software should work. For example, we debated the best way to implement transliterations for many months until we realized that we didn't have to choose between different transliteration systems -- we could support all of them if we set up the proposed "transliterated value" fields as infinitely repeating "multi-fields".

Similarly, we could make the "Directory Entry" field a "multi-field", at which point we could make this author appear in the Author Directory under "La Motte-Fouque" and under "Fouque". It would also facilitate creating Author Directories for other alphabets/scripts, e.g. Айзек Азимов would appear under "Asimov" as well as under "Азимов".

The only catch is that directory entry values are also used to sort authors on certain Web pages. Unlike our "transliterated" fields, where the order of values is not important, the first entered "Directory Name" value would have to be used for sorting purposes, so the order would be significant. Still, it would be much better than the current system which restricts authors to only one position in the Author Directory. Ahasuerus 20:05, 10 June 2018 (EDT)

Having a "sorting name" and "directory name(s)" actually makes a lot of sense - leave the existing field just for sorting and add a brand new multi-field for the directory. That way we won't need to be extra careful about the order of names in the field. Annie 22:16, 10 June 2018 (EDT)
I can see how separating "sorting names" from "directory names" can make the design cleaner. However, wouldn't that result in data duplication since "sorting names" are a subset of "directory names"? Or are there cases where a sorting name is not one of the directory names? Ahasuerus 13:52, 11 June 2018 (EDT)
If you're going to manage this by storing the data in that multi-field in an ordered manner, then you could make the entry form have the first space labeled "Sorting name", the second "additional directory entry 1," etc. ,-Vasha 14:00, 11 June 2018 (EDT)
And as one of the resident editors with a language that does not use the Latin alphabet, being able to use non-Latin names in the directory field (and being able to find them under those name) will be a great improvement. Annie 22:16, 10 June 2018 (EDT)
Earlier today I spent a couple of hours experimenting with Cyrillic alphabets. There are quite a few of them. They all share the same core letters of the Cyrillic script, but some alphabets add less common characters to the "alphabet soup". If we were to support all of them in a hypothetical "Cyrillic Author Directory", we would end up with a "60 by 60" or "70 by 70" grid, which would be unwieldy.
Of course, we have the same problem with Latin alphabets. We get around it by replacing accented letters with their unaccented counterparts in the Directory Entry field, which lets us keep the directory grid manageable. We could use the same approach for Cyrillic languages, but it would only get us so far. For example, I can't think of "unaccented" analogs of the Serbian "ђ", "џ" or "ћ" which would make any kind of sense.
We'll have to think about this some more. Perhaps we could get away with a simple alphabetized list of all Cyrillic characters:
  • А
  • Б
  • В
etc instead of a grid. Ahasuerus 13:52, 11 June 2018 (EDT)
Technically, if we do it completely, it should be a directory per language (that will also solve the whole German vs English vs Dutch sorting and policies on what is called last name). But I will leave that pink pony alone for now. :)
I would agree that a list based on the first letter is enough for now -- we can expand that later but we do not have that many authors that will have a Cyrillic based spelling (no point adding it if the author is not published anywhere in the Cyrillic script world and frankly, you never know how the publishers will decide to spell one's name). Now - that is not as feasible for Japanese and Chinese - way too many characters there... Still doable but...
However - if you are thinking of a "divide and conquer" solution where we sort the exotic alphabets one by one, I am all for it. Annie 14:24, 11 June 2018 (EDT)
To put Chinese characters in order, you group them by radical then order by stroke count. However, I'm told that it's more common to alphabetized according to pinyin transliteration nowadays. --Vasha 14:56, 11 June 2018 (EDT)
I know how to order them - I was just commenting on the length of the list for them (for a first character list) compared to the list for an alphabet-based writing. As for what is more common - that depends on where you look :) Annie 16:22, 11 June 2018 (EDT)

(unindent) Hmm.... We also had a suggestion to add a field to enter the name without all the non-latin characters (you need that for the sake of searching, and right now it is being put in the transliteration field, where it doesn't really belong, being a different thing). If we implemented all of these things, the data entry form would be really long and complicated. Transliteration (multiple) and "latinized" form, then legal.name and transliteration of it, then sorting name, then multiple directory entries. I feel like I could deal with this just fine but it'd be intimidating at first. At least this would all be invisible except when editing the data. --Vasha 00:01, 11 June 2018 (EDT)

Changes to the image upload process

The image upload process has been modified. The new version automatically adds the database ID of the artist to the template, which should facilitate linking artists whose names contain accented and/or non-Latin characters. Please note that at this time the new functionality is only available for publications with one cover artist. Ahasuerus 11:11, 7 June 2018 (EDT)

Add Tercera Fundación to external IDs?

La Tercera Fundación is a remarkably complete source of secondary information about Spanish-language spec fic publications. I have been trying to include the LTF record number in the notes of Spanish publications that I add, and I've noticed that I'm not the only one who's done that. Would it be worthwhile adding LTF to the external IDs? They have a simple way of generating URls: http://www.tercerafundacion.net/biblioteca/ver/libro/<ID>. I cannot guarantee that their record IDs are stable, but I did check one that was noted down five years ago, and it's still accurate. --Vasha 12:23, 7 June 2018 (EDT)

I believe that you mentioned that you have an account there? Any chance you can discover how often the IDs change? Annie 12:27, 7 June 2018 (EDT)
Would it be possible to ask them if their IDs are stable and whether they plan to keep them that way? Ahasuerus 12:27, 7 June 2018 (EDT)
How about adding a template in the meantime? We have the links now anyway, having them as a template will reduce the number of technical mistakes and if they ever change the format, we can swap them easily. No need to conver the existing links yet but the new ones will be safe. And it will be easy to convert them out if the external identifier is added. Annie 00:48, 8 June 2018 (EDT)
Well, templates and external IDs usually go hand in hand. If we determine that La Tercera Fundación's IDs are stable, we will create a new template and a new external ID. If, on the other hand, we determine that their IDs are not stable, we probably won't want to create either. Ahasuerus 09:45, 8 June 2018 (EDT)
We had templates much longer than identifiers though - although I see your point. I was thinking about the ability to identify them easier but that link seems to be pretty standard (and the address is long enough) so that should not be as much of s problem as it is with some of the other ones. Just links it is then until we can figure out the stability. Annie 14:17, 8 June 2018 (EDT)

I still haven't figured out who to write to in order to ask about this. I will let you know when I do. --Vasha 15:30, 8 June 2018 (EDT)

Thanks for looking into this! Ahasuerus 15:36, 8 June 2018 (EDT)
Maybe try their forums? Annie 17:13, 8 June 2018 (EDT)

Hello, I am the technical chief of La Tercera Fundacion. The user Vasha contacted us in our forums regarding this question. The record IDs of LTF are the primary keys of the database and thus are immutable (we only have changed or deleted records when we have detected significant errors on the data). Also, if we can do anything in order to ease the linking process, do not hesitate on contacting us. --Francis Gerard 10:16, 10 June 2018 (CEST)

Thanks a lot! I have created FR 1157 and added its implementation to the development queue. Ahasuerus 09:43, 10 June 2018 (EDT)

Libro vs. Ficha

I was poking around at the notes that we have and we seem to have two separate types of URL around the DB:

If I am reading this correctly, the "libro" one is the one for a publication; the "ficha" one is for what we consider a title around here. Which means that all these ficha links will need to be changed if we are going to use an external ID on the pub level (even when there seems to be 1 book only inside of it - there may be more later (like here. Or am I missing something? Annie 18:37, 11 June 2018 (EDT)

You are exactly right. It would have been easy to mistakenly link to the ficha/title record (and I see that some of those mistakes are by me, ouch) but all the links should be changed to the libro/publication record. --Vasha 18:49, 11 June 2018 (EDT)
So we probably should do as we did with the FantLab and the SFBG links - 1 external ID (for libro/book), 2 templates (for ficha/title and libro/book) (because you may want to link to the ficha one in notes somewhere). And when we are moving the ficha ones, whoever does it, needs to click through and find the correct libro. Annie 18:53, 11 June 2018 (EDT)
Yep; and unfortunately the IDs for ficha and libro have the same form, so there is no automatic way to spot that you have the wrong one. The editors and moderators will just have to be mindful of clicking through to double-check when a new one is added. --Vasha 18:57, 11 June 2018 (EDT)
FantLab is the same in the characters that matter (which is what we use in the field and in the templates) - I always check that the external ID is the proper type of ID and someone did not copy from the wrong page. Plus anyone submitting should be checking their links post submitting in all cases anyway so an editor should spot easily enough that this link is not correct so between the editor and the moderator, someone should catch the mistaken ones. Annie 19:02, 11 June 2018 (EDT)

Naming the templates and the ID type

It sounds like we are ready to implement this functionality. What should we use as the display names for the two templates (ficha and libro) and the new external ID type? Ahasuerus 13:44, 12 June 2018 (EDT)

For the templates: LTF-title (ficha) and LTF-pub (libro) to keep it consistent with the FantLab and SFBG ones? And I woult think that LTF should be ok for the external ID. Annie 14:00, 12 June 2018 (EDT)
Sounds reasonable. If there are no other ideas, I will start working on it tomorrow. Ahasuerus 20:37, 12 June 2018 (EDT)

Outcome

The FR has been implemented. A new external ID, "LTF", has been added. Two new templates, "LTF-title" and "LTF-pub", are now supported. Help:Using Templates and HTML in Note Fields has been updated. Ahasuerus 18:08, 13 June 2018 (EDT)

Great, thanks. And I just fixed a typo on the Help page. --Vasha (cazadora de tildes) 18:59, 13 June 2018 (EDT)

Marie, Queen of Roumania (names)

The discussion of Friedrich Fouque above prompted me to check Marie, Queen of Roumania, under that name and pseudonyms. I added most of the novel title and publication records myself perhaps a year ago. Probably we have changed the design concerning Legal Name and Directory Name fields since then.

Let me begin by asking what is and should be the criterion for "Directory entry: Roumania", which is the current value for all three of her names in the database. --Pwendt|talk 13:57, 7 June 2018 (EDT)

As it is the last part of the name, the software will automatically use Roumania as the directory name on all the variants - so I doubt that there was a human decision involved... I wonder if in this case, the complete name should not be the directory entry (as she has no last name and people would look for her under Marie in her main entry). The pseudonyms are a bit weird but it does not matter what we chose there - chances are that noone will look under any of the letters anyway. Annie 14:16, 7 June 2018 (EDT)
Both pseudonyms are supported by title page images that show "by the". The relevant lines in title page layout begin once with "the" 1913 at HathiTrust and once with "by the" 1915 as Ebook #40950. The canonical name is also supported by one pre-1923 title page image 1916 at HathiTrust and it matches what library records report for the later works. ...
I agree that "Marie, Queen of Roumania" would be a good choice. Ahasuerus 17:22, 7 June 2018 (EDT)
The Library of Congress uses canonical name "Marie, Queen, consort of Ferdinand I, King of Romania, 1875-1938", LCCN: n50-43679; that, too, is directory entry under "Marie,". --Pwendt|talk 17:31, 8 June 2018 (EDT)

Cover photography, cover design

The two COVERART titles 990980 and 712113 should be revised and merged. Their four publications in the database are reported 3rd to 6th printings of one 2000 edition. Two database contributors have credited the photographer alone and two the designer alone. Just now with a copy of the 6th printing in hand I submitted a title Note that quotes both credits Submission #3863640. --Pwendt|talk 17:39, 11 June 2018 (EDT)

As we do not credit designers (just illustrators for the most part), the one blocking the merge is actually your PV'd one that credits the designer. If you want to switch it over, I will fix the other one that is there with yours and we all can meet under the photographer... Or do you think that the designer needs to be credited here? That's a very slippery slope. Annie 13:44, 12 June 2018 (EDT)
Offhand I prefer to minimize the numbers of both photographers and book designers in the database. But it's valuable to identify publications that share a cover illustration, and covers that look identical as in this case, and assignment of cover art author credit is essential for that, under our design, I understand.
I moved the COVERART title Note from 712113 to 990980 and submitted both Remove 712113 and Import 990980 for both of the 712113 publication records --5 submissions. That will leave title 712113 to be deleted. --Pwendt|talk 19:03, 13 June 2018 (EDT)
I wiped it out of existence as soon as you jettisoned it out from the last of its publications :) Annie 19:10, 13 June 2018 (EDT)

Bruno Frank's The Magician and Other Stories

The Magician and Other Stories was a posthumous (1946) collection of Bruno Frank's stories. I can't find any evidence to suggest that it contains speculative fiction. Here is what Kirkus Review had to say about it:

"A goodly collection of short stories, notable for their serenity and un-sensationalism, well written and translated so that never are you conscious of the translator. There's a story here for every taste, mostly about Germans of the upper-class, usually intellectuals, and all but one pre-Hitler. Frank has the knack of packing the whole of an impression and a situation into the bounds of a real short story. The stories are romantic, philosophical, always credible and never sensational nor violent, even when dealing with crime. Perhaps most noteworthy of all is his ability to create characters quickly and attitudes neatly. Quiet humor, a fine polish, and intelligence -- stories which all who enjoy this form will find worth reading."

W. Somerset Maugham's introduction is also available online, but it doesn't say much about the stories.

I suspect that the book may have been added because it has the world "Magician" in the title. Would anyone happen to know more about this? Ahasuerus 13:06, 13 June 2018 (EDT)

Series, Magazines and Fanzines migrated to the database

Now that all Wiki-based Series, Magazine and Fanzine pages have been either migrated to the database side or linked via the "Web pages" field, Series pages no longer need to display Wiki links based on the infamous "lexical match." (If you weren't around when SERIALs were linked "lexically", consider yourself lucky.) The software has been updated accordingly. Ahasuerus 19:15, 13 June 2018 (EDT)

Do the 12 relevant reports self-retire or do you need to retire them manually (in case you did not do that already of course)? Annie 19:29, 13 June 2018 (EDT)
The next time the reports run, they should find 0 matching Wiki pages, so they won't appear on the standard list of cleanup reports. I plan to keep them around for some time in case an editor degafiates and uses the old method of entering the data. I expect that we will eventually deactivate them in order to speed up the nightly regeneration process. Ahasuerus 19:49, 13 June 2018 (EDT)
As long as these 5 get off the list (they are all linked somewhere - Winston is on pub series; the other 4 on regular ones but with different names. Annie 20:08, 13 June 2018 (EDT)
I guess we can do it one of two ways: I can disable this particular report or we can move the five affected Wiki pages to a different namespace. I would prefer not to disable the report for now, so I wonder if there is anything preventing us from changing the namespaces? Ahasuerus 20:32, 13 June 2018 (EDT)
Moving them sounds like a plan. Do you need me to give you the 5 places there are linked at or do you have them? Annie 20:39, 13 June 2018 (EDT)
As long as these 5 Wiki pages are linked on the database side, we should be fine. We'll just need to adjust the URLs in the "Webpages" field in case their Wiki directs are zapped at some future point. Ahasuerus 21:00, 13 June 2018 (EDT)
Badly worded question on my side. I was asking if you need me to list the 5 entries in the DB where these 5 are linked :) Annie 21:08, 13 June 2018 (EDT)
Hm. It looks like these five pages may benefit from a more in-depth review. For example, Series:Star Trek Pocket Books is, for the most part, a duplicate of this publication series in the database. We may be able to delete it and, perhaps, the other 4 pages once we copy any non-duplicate data to the database. Ahasuerus 22:50, 13 June 2018 (EDT)
Probably although it is not just these 5 if you really want to eliminate the wiki completely. I have the Star Trek one on my list of things to look at and untangle but I just do not have the patience for it today. But the other 4 either contain pictures (the Winston - and the wiki is much better suited for that) or can be recreated in the notes but the effort is substantial (which was one of the ground rules for keeping them as links although I hated leaving links behind so they had to be really messy for me not to move the data). Which is why I said that at some point we need to review all local wiki pages now linked - data evolves and these do not change anymore and as long as there are no pictures, moving them comes down to time and effort only. If you rather have them stay on the report until someone decides to work on them - we can do that. Phase 2 of the cleaning of the wiki I guess. Annie 23:07, 13 June 2018 (EDT)
Make that just 3 actually - two of them (ST and Mammoth) are still resolvable with some patience but we still have the Winston one to deal with. But we may want to group those linked pages - not just the ones here but all linked through the DB in a separate set of new namespaces that make it clear that they are linked in the DB. But that is again Phase 2 in my book. At the end of the day, the less we have in the wiki, the less likely to lose information (based on how we do backups). Annie 23:20, 13 June 2018 (EDT)
Makes sense. I was just observing that Series:Star Trek Pocket Books looked like it should be doable -- it was originally created back when we had no support for publication series, so most of its data is duplicative. The Winston page can be moved to a different Wiki namespace for now, so that it wouldn't appear on this cleanup report anymore.
Re: creating a way to track Wiki pages that the database links to, I think it's an interesting idea, but we may need to think about it some more. There are a few different ways to skin this particular cat (no offense to cats!) Ahasuerus 23:26, 13 June 2018 (EDT)
Oh, it is doable. Guess I will look at it and the Mammoth one again later this week - my brain can handle just some replacements at the moment and this will need some concetration. As for the tracking - thus me calling it Phase 2 :) One step at a time - someone around here had a quote about striving to perfection :) It seems to apply to this. Annie 23:41, 13 June 2018 (EDT)

Security upgrade - Phase 2

The second phase of the security upgrade is now underway. The way the "+" signs associated with "multi-fields" are handled has been changed. The only user-experienced change is that the label of the "Author" field has been standardized across edit forms. In the past the software tried to display "Author" or "Editor" depending on the context, but it did it inconsistently, creating more confusion that clarity. For now I have changed the label to "Author" and will revisit it at a later point.

The changes were fairly extensively, so a full page reload (Control-F5 in most browsers) will be needed. If you see anything odd, please report your findings here. Ahasuerus 18:32, 15 June 2018 (EDT)

There is something odd in Firefox but not Microsoft Edge (the only two browsers I have to compare). In Advanced Search the first dropdown box in Publication Search is not showing up (see screenshot). --Vasha (cazadora de tildes) 19:07, 15 June 2018 (EDT)
CTRL + F5 or restart FF (or both)? Loosk fine for me in FF (60.0.2). Annie 19:17, 15 June 2018 (EDT)
No, I did completely restart. And what's more I cannot edit in Microsoft Edge at all! (keep gettin "Error: Invalid Publication Type" when I submit anything). --Vasha (cazadora de tildes) 19:21, 15 June 2018 (EDT)
Reboot. And do a Ctrl + F5 (if you are on Windows). There may be a cache somewhere on the networking layers. Annie 19:26, 15 June 2018 (EDT)
Neither of those helps. --Vasha (cazadora de tildes) 19:35, 15 June 2018 (EDT)
Plugins? Disable them all, see if that helps and then start enabling them one by one until you find the offending one? Annie 20:12, 15 June 2018 (EDT)
A quick review suggests that Internet Explorer 11 is not happy with the latest round of changes. Firefox (with NoScript, but no other plugins) and Chrome appear to be OK. Investigating... Ahasuerus 20:29, 15 June 2018 (EDT)
Annie was right, it was Adblocker Ultimate that was messing with the search page. I am going to test some other adblockers now. --Vasha (cazadora de tildes) 20:33, 15 June 2018 (EDT)
In related news, I have found the code that Internet Explorer was unhappy with. It's supported by all other browsers (and the relevant standards), but it wasn't implemented in IE before it was superseded by Edge. Let me see if I can fix it real quick. Ahasuerus 20:37, 15 June 2018 (EDT)

(unindent) The problem with Internet Explorer has been fixed. You may need to restart it before the fix takes effect -- Control-F5 doesn't always work cleanly under IE.

Unfortunately, I am unable to test Edge since the development server is running Windows 7. (It may be possible to get IE11 to work in a VM environment, but I haven't experimented with it yet.) Are you still experiencing problems, Vasha?

P.S. I have added additional validation to prevent confused browsers from submitting publications with invalid formats. Ahasuerus 21:12, 15 June 2018 (EDT)

I am getting reports indicating that the changes deployed on 2018-06-14 made "isfdb.org" (as opposed to "www.isfdb.org") effectively inaccessible. Although "isfdb.org" has never been officially supported, we need to make it redirect to "www.isfdb.org" cleanly and transparently. I will need to make changes to our Web server settings, which may cause brief outages while I am tinkering with the server setup. I expect to start working on it on Saturday morning and will post an update when I am done. Ahasuerus 21:22, 15 June 2018 (EDT)
No, Edge is not working, although I refreshed and restarted it. --Vasha (cazadora de tildes) 21:43, 15 June 2018 (EDT)
I was hoping that the IE fixes would also help Edge, but apparently not. Any other Edge users experiencing problems?
Also, Vasha, is the Edge error message consistently "Error: Invalid Publication Type"? If so, it suggests that Edge doesn't create the list of publication types correctly when it builds the Publication Editor page. Could you please access the Publication Editor page, pull up the source code (Control-U), copy the text and upload it to a Wiki page? In addition, if you press F12 when you are on the Publication Editor page and select the "Console" tab, it will display a list of errors and warnings that Edge is unhappy about -- here is a screenshot and a brief guide. Ahasuerus 22:00, 15 June 2018 (EDT)
I get that warning when trying to submit edits to every type of publication I have tried so far (but no problem with title edits). I have copied the code & console messages here. --Vasha (cazadora de tildes) 22:29, 15 June 2018 (EDT)
Thanks, investigating... Ahasuerus 22:54, 15 June 2018 (EDT)
I had a problem earlier this week with Edge and certain pub types (pb and tp), but not others (ebook). It would put a extra character on the end, even though I was picking things out of the combo menu. I just tried now and cannot reproduce it, but I had been doing a lot more form-based editing when I ran into it than I had been doing tonight. --MartyD 23:01, 15 June 2018 (EDT)
Thanks, Marty! I have checked the HTML that Vasha posted against the W3C validator and it looks fine. My best guess is that it adds an extra character to some values when it sends the form data to the server. Let me modify the error processing logic to display the "bad" data -- it may help with reporting.
Re: the errors and warnings that Edge displays in F12, they look similar to what IE 11 displays and are generally harmless. "Numeric character reference does not resolve to a valid character" is just Microsoft's way of complaining about Unicode characters. The fact that Edge doesn't support 'manifest-src' shouldn't matter because it ignores it. Ahasuerus 23:09, 15 June 2018 (EDT)

(unindent) It turns out that this is a known issue with the current version of Edge. According to a Microsoft employee:

  • ... a fix has already been written, and servicing is in progress. I’m not the person responsible for the team writing the servicing fix, but I think the update should be part of the next patch Tuesday, which is (I think) due on the second Tuesday of the month of June.

The MS employee also suggested a workaround. Let me see if I can implement it real quick. Ahasuerus 23:23, 15 June 2018 (EDT)

OK, a partial workaround has been installed. I have no way of running Edge, but it *may* (emphasis on "may") make Edit Pub work under Edge. Please note that it's not a comprehensive fix: even if it works, it only applies to Edit Title and Edit/Add/Clone/New Pub. It would take a lot of testing to implement this workaround everywhere. Since it's not guaranteed to work and since Microsoft plans to fix Edge shortly, I think I'll stop here. Ahasuerus 14:51, 16 June 2018 (EDT)

Default external ID preference?

Would it be possible to have the option in Preferences to choose which external ID comes up at the top of the list by default? --Vasha (cazadora de tildes) 09:56, 16 June 2018 (EDT)

Technically speaking, it's possible and not particularly difficult. If there is enough demand for it, we can move it up the list of priorities. Ahasuerus 10:24, 16 June 2018 (EDT)

"isfdb.org" fixed

The security patches installed on 2018-06-14 affected our users' ability to view "http://isfdb.org" -- note the absence of "www" in the URL. I have deployed a patch to make "http://isfdb.org" behave the way it behaved 3 days ago.

P.S. Please note that using "isfdb.org" instead of "www.isfdb.org" is not (and has never been) recommended because it keeps a separate copy of your login information, which can result in confusing login/logout messages. Ahasuerus 18:49, 16 June 2018 (EDT)

Security upgrade - Phase 3

The way "New Cover/Title/Review/Interview" buttons work has been tweaked. There should be no user-experienced changes. A full page reload (Control-F5 in most browsers) may be required for everything to work correctly. Ahasuerus 13:28, 17 June 2018 (EDT)

A big change today -- the "Add" buttons on New/Edit/Add/Clone Pub pages have redone. A full page reload (Control-F5 in most browsers) is required. If you run into anything odd, please describe the details here. Ahasuerus 17:33, 18 June 2018 (EDT)
Another patch has been installed. It leveraged the software changes made over the last 2 weeks to tighten our security settings. In theory, it shouldn't affect the software behavior, but it's hard to be 100% sure because some things are browser-specific. If you see anything unusual, especially with pop-up validation and/or mouseover behavior, please post you findings here. Ahasuerus 11:18, 19 June 2018 (EDT)
The final patch in the current series of security patches has been installed. The core ISFDB software is now fully compliant with CSP best practices and security has been tightened accordingly. It's not the final word in the security saga, but it's a big step in the right direction. Please note that a number of "stats" graphs may not display correctly until tomorrow morning. Ahasuerus 16:41, 19 June 2018 (EDT)

Authors By Debut Year tweaked

Authors By Debut Year has been tweaked to display transliterated author names. The header has been changed to mention the fact that the report is limited to authors with at least 6 eligible titles (novels, short fiction, serials, poems or collections.) Ahasuerus 11:53, 19 June 2018 (EDT)

Any chance this report can be changed to show the split of works based on type (I'd be interested in someone with 10 novels but I really do not care about someone with 10 poems for example)? Not urgent of course - I was just wondering. Annie 13:47, 19 June 2018 (EDT)
I agree that the current selection logic is not perfect. There are a few different ways we could improve it. For example, we could change the eligibility criteria to something like:
  • All authors with at least X book-length works [novels, collections, anthologies (?), EDITOR (?)] OR Y fiction [any length] works
We just need to decide what makes the most sense. Also, given the length of the list and the fact that it's already sorted by year, it may be better to change the main page from a list to an annual grid. Ahasuerus 14:34, 19 June 2018 (EDT)
And that would miss someone like Ted Chiang - who does not have enough full length works but excluding him makes no sense at all considering the awards and all that. Thus the idea of a "per type" columns - we include everyone that published the required 6 pieces of fiction but we show the different numbers per type as well so people can look for whatever interests them the most. —The preceding unsigned comment was added by Anniemod (talkcontribs) .
It depends on the values of X and Y. If we make X, say, 2 and Y 6, then anyone with 6+ stories will be eligible even if they haven't published any book-length works. Ahasuerus 14:49, 19 June 2018 (EDT)
Ah, I missed that part. But it will still not make a difference between someone with 10 poems and someone with 10 stories (poetry vs prose) which is what I usually care about. But then not all reports should do what I really want them to - so just thinking aloud :) Annie 15:11, 19 June 2018 (EDT)
And looking at some of those numbers, our treatment of excerpts as short fiction makes some of those number inconsistent (really depends on the editors and if the excerpts at the end of novels are added or not). I wonder if it is not time for a new flag on the short fiction level (excerpt) so these can be filterable... Annie 13:47, 19 June 2018 (EDT)
In the past, there were some technical issues associated with adding new "length" values, but they were resolved last year. At this point it should be easy to add anything we want, we just need to reach consensus. The last discussion was inconclusive, but we made a fair amount of progress. Perhaps the next round will be final. Ahasuerus 14:42, 19 June 2018 (EDT)

(unindent) After sleeping on it, I came up with a different design and rewrote this report. The main page has been converted from a list of decades to a year grid, which should make individual pages more manageable. The new data will become available when the nightly process runs at 1am server time. Ahasuerus 20:10, 20 June 2018 (EDT)

I like it - it loads faster :) Although a quick look through some pages made me realize that we have a lot of authors in the wrong year - because we do not have their first works (especially the non-English ones). I've always known that of course - but the split into years made me notice it even more. Annie 17:08, 21 June 2018 (EDT)
Non-genre authors can be particularly misleading. Consider E. Phillips Oppenheim or P. G. Wodehouse. Ahasuerus 17:15, 21 June 2018 (EDT)
Oh yes... there is that as well. I was mostly looking at the small presses ones - where some of our coverage is still lacking. The few I checked from the 2018 lists are not 2018 debuts. I think I will put that on my list of things to work on - get the current year list and see if any of them have earlier publications (the ones I looked at cannot be caught with the public Fixer pages because the debuts are in anthologies...). Then start moving back in time. Annie 17:19, 21 June 2018 (EDT)
Sounds like a good plan! Ahasuerus 17:26, 21 June 2018 (EDT)
Except that it creates exponential amount of work - adding an anthology to get one's story adds 10+ new (or newish) authors which also need to have their complete list added and so on in perpetuity. That would take while. :) Annie 18:33, 21 June 2018 (EDT)

Science Fiction & Fantasy Translation Awards

(Moved from user's page--Vasha (cazadora de tildes) 08:56, 21 June 2018 (EDT))

I would like to add a SF&F Translation Award to a title, but couldn't find the award on the list. May I request to add this award onto the award list? Although it's in defunction, it's quite authoritative and influential during its four-year life. See: https://en.wikipedia.org/wiki/Science_Fiction_%26_Fantasy_Translation_Awards Its official site is still working. http://www.sfftawards.org/ sanfeng 05:26, 21 June 2018 (EDT)

Our software doesn't support awards given to translators (at least not well.) However, it looks like these awards were given to authors as well as translators, so there shouldn't be a problem. Ahasuerus 10:01, 21 June 2018 (EDT)
Thanks for considering adding this award. sanfeng 01:02, 22 June 2018 (EDT)
If there are no objections, I will plan to add this award tomorrow night (server time.) Ahasuerus 14:28, 22 June 2018 (EDT)

Most-viewed titles tweaked

The lists of most-viewed novels and short fiction have been tweaked to display the title year. They have also been changed to display 500 titles to match the list of most-viewed authors. Ahasuerus 11:34, 21 June 2018 (EDT)

Are those unique hits or all hits? Annie 16:53, 21 June 2018 (EDT)
It's a count of all Web page views -- every time a page is displayed, a counter is increment within the title record. Unfortunately, variants and translations are not counted at this time, which skews the picture quite a bit. I'd like to rewrite the logic to include VTs the way some award reports do. Ahasuerus 17:01, 21 June 2018 (EDT)
Thanks! That makes sense. I know that I am hitting some pages all the time because my auto complete defaults on them so I was just wondering. Annie 17:04, 21 June 2018 (EDT)

Adding empty anthologies, magazines and collections

I had been trying to work through a few of the debut authors from 2018 and figure out if they are indeed that new and I kept stumbling on collections and anthologies that had been added months (and sometimes years) after release (so the content was already available) and which were either left empty or with a single story entered (presumably by the author or their representative). What is the point of having these in the DB if we do not have the fiction records?

We have a report: Container Titles in Publications with no Contents but it requires one of the publications to have content so most of the 20xx anthologies and collections (and virtually all of the small press ones) do not make the cut (as they are yet to be reprinted so there is a single publication).

With this in mind, I had been thinking about 2 things:

  • Add a new template {{Content incomplete}} that populates as "Content not (entirely) clear yet" that can be used when an anthology/collection/magazine is either too new or too old (or is still forthcoming) and there is no way to find the complete content so these can be tracked and populated later. And automatically add this tag to all collections and anthologies and magazines in the DB that do not have at least one fiction title.
  • Require that the content be entered when the publication is entered (or with an edit/import after that).

None of this will require changes in the software (except adding the template and the automated adding of the tag to the old records); it is just a small policy change that will ensure that we actually add the books completely... Thoughts? Annie 20:24, 21 June 2018 (EDT)

This topic was discussed back in January. The outcome was the creation of FR 1120, "Automate the anthology/collection tracker".
My current thinking is that templates would work, but it may be better to create a new field in publication records. The supported values would be something like "Fiction Contents Complete" and "Fiction Contents Incomplete". It would make the report generation process much faster and won't require editors to memorize additional template names. Ahasuerus 20:43, 21 June 2018 (EDT)
I vaguely remember that discussion now that you mention it - I think it was in between a few of my business trips so I was mostly missing (and thus I did not think of it) :) I'll drop the topic then. Any timeline? Annie 20:57, 21 June 2018 (EDT)
My 2¢... It is a significant amount of work to add the contents of a collection or anthology, far trickier than adding the rest of the publication record. I don't really blame people for skipping over that; I would personally rather have a record of the publication in the database, even without contents. It's good to know what anthologies and collections exist. So I don't think it would be a good idea to require that all new anthologies and collections must be added with contents. Adding the contents to the thousands of publications that don't have them currently will take a very long time, but it's doable. A tool to make finding them easier would be nice. Sloppy or incomplete contents is a bigger problem than missing contents because it's a lot harder to find those. I do think that moderators should not be allowing inexperienced users to add partial contents (though that doesn't help with the ones that already exist).
As to the suggestion of a field. It's a good idea, but would be much more useful if associated with notes. If there weren't notes, I'd want it divided among more levels or categories of completeness. This field, with notes, would mostly replace the tracker, which would then only be used for keeping an eye out for forthcoming ones that haven't been added to the database yet. Unfortunately, it could not be automatically populated for existing publications, apart from ones with no contents being set to incomplete. --Vasha (cazadora de tildes) 22:20, 21 June 2018 (EDT)
So if someone skips the content even when it is available, they should just skip the book altogether. Once the book is in the system, people that first check by ISBN before adding new books may not even open the book - assuming that whoever added it did it properly. While there may be some value in having an empty container in the DB, we are a fiction DB - I find the fiction to be the most important part here... But to each their own. Annie 22:43, 21 June 2018 (EDT)
I try to find as many 2018 anthologies/collections as I can, but I don't spot them all; and it is really useful to have other people adding them to the database. Please do not make them avoid doing so just because they don't have the contents (they may genuinely not be able to find them out yet). As to the problem of not noticing that it has no contents when you look it up... Don't we have something called "bibliographic warnings" that you can display optionally in preferences? I don't know what that is but it sounds like the right kind of thing. --Vasha (cazadora de tildes) 22:56, 21 June 2018 (EDT)
Want to reread what I said above? I am not talking about new anthologies that noone has the content of or old ones that need someone to go to a library for (thus the request for the template so we can have them and tag them properly) but someone adding a 2017 Kindle and/or small press anthology in 2018 has access to the content (for example). Lack of content is not one of the things that the bibliographic warnings are checking for - they check for things like missing prices, unknown formats and so on. Annie 23:12, 21 June 2018 (EDT)
I have come across a number of different scenarios which lead to the creation of contents-less container titles. The most common one is Fixer finding and adding new anthologies/collections. Unfortunately, more often than not I don't have the bandwidth to add the contents items even if they are available via Look Inside or the publisher's Web site, so the added containers remain "empty" until someone comes along and adds the stories. Hopefully, things will improve once we revamp our handling of Fixer's data. Ahasuerus 23:27, 21 June 2018 (EDT)
True... although Fixer's submissions are easy to spot - not that easy to find. I wonder if we cannot figure out a special template just for Fixer (regardless if he submits on his own or you do it for him) which will allow someone to find the book and submit the contents later? Especially on the AddPub when Fixer knows it is a collection/anthology (it can be added manually when a moderator handles a NewPub that needs type change)? I just think we should encourage people a bit more to enter the contents of the books they are adding - not stop them from adding without content but make it clear that it is recommended. Annie 23:52, 21 June 2018 (EDT)
Hm, it's a thought. Let me sleep on it... Ahasuerus 00:13, 22 June 2018 (EDT)
With amazon's look inside there's also the problem that the types of the contents are not always clear: there is a difference between SHORTFICTION and POEMS, for example (or it may be in fact an ESSAY). I do add the contents if they are clear (because the text is displayed, the type is mentioned, or the title is already in the database), but I think it'd be better to leave a title out, for which the type can only be guessed than to have a possible erroneous statement. I do enter a note that the contents are incomplete, though. Stonecreek 05:48, 22 June 2018 (EDT)
Seconding Stonecreek's opinion. Also, for example, this publication was added from Amazon with complete contents and the note "Unclear whether all of the stories are genre." Personally my practice would be to glance through reviews and descriptions and only index the stories I think are genre, with the others listed in notes, to be shifted to the contents if they do turn out to be genre. But that's just my own thoughts. --Vasha (cazadora de tildes) 11:30, 22 June 2018 (EDT)
Common sense is always needed and corner cases will always exist. But there are enough cases where it is obvious that it is one of our anthologies/collections. And as long as people actually record their decision ("content not added as it is not clear which stories are genre", that is still better than what we do now in a lot of cases. Annie 12:11, 22 June 2018 (EDT)

(unindent) It sounds like we have two separate issues here. The first one is encouraging editors to add Contents titles to submitted publications. I think it's a worthy goal, although, as per the discussion above, there are various limitations that we have to deal with.

The second one is making it easier to find Contents-less publications. I have reviewed and reworked FR 1120, which should, hopefully, better reflect the desired functionality. Does the new design look like it should cover most of the bases? Ahasuerus 14:26, 22 June 2018 (EDT)

Could we have a report that lists ANTHOLOGY, COLLECTION, MAGAZINE, and OMNIBUS records with 3 or fewer content title entries? It should have an ignore button in case the item really does only have 3 or few content titles. This would at least give a place where they could all be found easily. ···日本穣 · 投稿 · Talk to Nihonjoe 15:13, 22 June 2018 (EDT)
It would be easy to do, although I would exclude OMNIBUSES, which already have a separate cleanup report. The main problem is that it would find a lot of eligible pubs. Counting just ANTHOLOGIES, COLLECTIONS, MAGAZINES with N fiction (SHORTFICTION, POEM, NOVEL, SERIAL) titles, here is what we have at the moment:
  • N is 0, i.e. "empty" containers: 12,139
  • N is 1: 16,447
  • N is 2: 7,985
  • N is 3: 5,444
Another problem is that we don't necessarily want to ignore publications with unavailable Contents titles. What's unknown today may become known tomorrow. Ahasuerus 15:59, 22 June 2018 (EDT)
I don't see the problem with that. It's true there's a lot of empty or nearly empty containers, but we knew that. To break the list up into smaller pieces, maybe divide them by years because the more recent ones will usually be easier to find information about. --Vasha (cazadora de tildes) 17:33, 22 June 2018 (EDT)
That's a good point. Breaking the list up by year would definitely make it more manageable. Here is how many fiction-less container pubs we have for the last 18 years:
| 2000 |             163 |
| 2001 |             202 |
| 2002 |             174 |
| 2003 |             178 |
| 2004 |             260 |
| 2005 |             228 |
| 2006 |             169 |
| 2007 |             251 |
| 2008 |             381 |
| 2009 |             387 |
| 2010 |             553 |
| 2011 |             619 |
| 2012 |             684 |
| 2013 |             651 |
| 2014 |             674 |
| 2015 |             631 |
| 2016 |             653 |
| 2017 |             561 |
| 2018 |             170 |
| 8888 |              50 |
The problem is that the standard cleanup software doesn't support this level of granularity. I would have to create a custom report, but it's certainly feasible and much easier than adding another field to publication records. Ahasuerus 18:15, 22 June 2018 (EDT)
And your second objection, I don't understand. Do you mean that we should somehow have two ways of marking records we have examined, one being "ignore" (the contents are correct as is) and the other (a tag or template?) saying "I have looked for information about this publication's contents and couldn't find any"? --Vasha (cazadora de tildes) 17:33, 22 June 2018 (EDT)
Yes, something like that. If we were to go with this approach, we would have 2 cleanup reports. The first one would run every night and find empty or near-empty container publications. It would let moderators mark publications "OK as is/ignore" or "Contents currently unknown".
The second cleanup report wouldn't need to be re-run nightly and would be limited to publications previously marked "Contents currently unknown". It would let moderators "ignore" publications.
The more I think about this approach, the more I like it compared to what FR 1120 currently envisions. The new cleanup reports would be non-standard, so they would require a certain amount of custom development, but nothing insurmountable. I think it would be a cleaner solution than adding a new field. Ahasuerus 18:25, 22 June 2018 (EDT)
Personal tools