ISFDB:Community Portal


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.
Verification requests
Help with bibliographic, image credit, and other questions which require a physical check of the work in question.
Rules and standards
Discussions about the rules and standards, as well as questions about interpretation and application of those rules.
NewRules changelogArchives
Community Portal
General discussion about anything not covered by the more specialized noticeboards to the left.
Moderator noticeboard
Get the attention of moderators regarding submission questions.
NewArchivesCancel submission

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

Expanded archive listing


To change titles or not

All publications under the variants here have the longer names (and the longer names match so we won't have multiple new variants). The title records have the short names. So - should we equalize on the long names or is that one of the legitimate cases where we should leave the title and pub title mismatched? I vote for equalizing - there aren't so many that the page will become unreadable if the variant titles get a bit longer and it will not be left as a precedent:) Anyone with an opinion? Anniemod 22:00, 15 November 2016 (UTC)

Any opinions? Anniemod 19:41, 17 November 2016 (UTC)
One of the affected pubs has been verified, so I would suggest asking the verifier what he thinks about the proposed change. Ahasuerus 21:41, 17 November 2016 (UTC)
(Since it was sitting at my feet, I verified my third edition to go with the already verified second edition.) The title page has three blocks: (1) Reginald's Science Fiction and Fantasy Awards (2) A Comprehensive Guide to the Awards and Their Winners (3) [in italics] Third Edition, Revised and Expanded.
LCCN link says "Uniform title: Science fiction and fantasy awards; Main title: Reginald's science fiction and fantasy awards : a comprehensive guide to the awards and their winners; Edition: 3rd ed., rev. and expanded". I suggest that we should use at least the LCCN "Main Title". But these multiple editions really are new versions of the book--they differ by much more than what would justify a "variant title" for a fiction book. Chavey 02:11, 18 November 2016 (UTC)

Change proposal - series transliteration

Publication series have transliterations while regular series don't. Any plans to add the fields there as well? And if not, can I propose to add them? (I had been looking at series such as this one that will look at lot cleaner if that second part can be moved to a transliteration... Anniemod 08:59, 16 November 2016 (UTC)

Regular (title) series present unique challenges. There is no "variant series" mechanism, so we stuff all known series names into the same field using slashes as delimiters. For example:
Similarly, we enter translated and transliterated series names in the same field, e.g. とある魔術の禁書目録 / Toaru Majutsu no Index / A Certain Magical Index or Волонтеры Вечности / The Stranger's Woes.
There is a Feature Request to add support for translations. However, I think we need to consider the issue holistically and decide what we want to do with variants, translations and transliterations at the same time. Ahasuerus 16:22, 16 November 2016 (UTC)

Default Size for Kanji and Kana

The default size for Kanji, and Kana are too small to read easily, especially at my age. Would it be possible to set the default a couple of notches larger?--Rkihara 17:55, 19 November 2016 (UTC)

If I understand the question correctly, you'd like to increase the font size of Kanji/Kana characters while keeping the font size used to display Latin, Cyrillic, Greek, etc characters the same. Is that about right? If so, then it should be possible, but it wouldn't be easy. The software would have to examine each and every character that it is about to display in order to determine whether it's Kanji/Kana. Is there an easy way to change font size in your browser? For example, in the Windows versions of Firefox, IE and Chrome all I need to do is press "Control" and then either "-" or "+". Ahasuerus 00:27, 20 November 2016 (UTC)
Sorry, I sometimes think people can read my mind. Most of my reading problems with kanji and kana are in editing, so when I'm entering characters, or transliterating, the small font size makes difficult for me to read. The problem being that the difference between two characters could be a tiny stroke. Maybe a button in the edit mode that enlarges all text, not just kanji, in the editing mode for simplicity? I do use command+ (Mac) to zoom sometimes, but that's inconvenient. It's not that easy for me to read the characters on the biblio pages either, but I can live with that.--Rkihara 08:52, 20 November 2016 (UTC)
Do you use a trackpad? If so, you can use the pinch zooming on it. If you use a mouse, hold down Command or Control and use the scroll wheel. ···日本穣 · 投稿 · Talk to Nihonjoe 18:15, 21 November 2016 (UTC)
Text with mouse zoom is fuzzy, zooming with command+ gives sharper text, but I have to zoom through 2-3 steps. I learned Japanese long after I learned English, and don't use it a lot, so I don't have the instant recognition of kanji as a unit of meaning, as a native reader would. I can read small, blurry, misspelled text in English fairly easily, but I can't do that with kanji or kana.--Rkihara 20:26, 21 November 2016 (UTC)
Hmm...I've never had a problem with it being fuzzy. I wonder why yours does it that way. ···日本穣 · 投稿 · Talk to Nihonjoe 22:20, 21 November 2016 (UTC)
Most browsers let you customize font settings. Perhaps the settings used by Ron's browser result in fuzziness for certain font sizes. Ahasuerus 22:26, 21 November 2016 (UTC)
Played around with it a bit. Apparently I've been doing it wrong. Control-Scroll zooms the screen, Command-Scroll zooms and re-renders the text. A lot better, but the zoom rate is hard to control.--Rkihara 05:37, 22 November 2016 (UTC)
Command-Scroll Zoom behavior on the author edit pages is very erratic, though well behaved elsewhere.--Rkihara 05:41, 22 November 2016 (UTC)
You can adjust how they work by going into the System Preferences | Accessibility | Zoom (I'm assuming you have MacOS, based on the above). ···日本穣 · 投稿 · Talk to Nihonjoe 20:31, 22 November 2016 (UTC)
Also, there is a minor HTML bug on the Author Editor page. It's not visible to the naked eye, but it may be confusing Ron's browser. Let me see if fixing the bug may help "unconfuse" the browser. Ahasuerus 20:51, 22 November 2016 (UTC)
The Author Editor bug has been fixed. Let's see if it helps. Ahasuerus 20:58, 22 November 2016 (UTC)
Zoom with scroll still erratic on author edit page. Zooms sometimes, then doesn't respond to input.--Rkihara 23:14, 22 November 2016 (UTC)
If the browser doesn't respond to input, then it's way beyond anything we can do on the server side. Granted, there are ways to create complex Web pages which will try to exploit browser vulnerabilities and/or install malware on your computer, but our software doesn't do anything remotely like that. Ahasuerus 23:38, 22 November 2016 (UTC)
I see. I can think of 2 approaches that may help. They both involve creating a new User Preference. The first approach would add a User Preference to control the font size of all ISFDB pages, i.e. bibliographic pages, edit pages and moderator pages. The second approach would add a User Preference to control the font size of editable fields on Edit pages. Which one would work best for you? Ahasuerus 19:10, 20 November 2016 (UTC)
I'd say the latter, being able to change the font size of editable fields, though the former might be useful for other people.--Rkihara 07:03, 21 November 2016 (UTC)
OK, I'll go ahead and create a Feature Request then. Ahasuerus 20:33, 21 November 2016 (UTC)
I like this idea, though I just use the Zoom feature which is in pretty much every browser. That way I can zoom in if needed, and then zoom out afterward. ···日本穣 · 投稿 · Talk to Nihonjoe 18:14, 21 November 2016 (UTC)

Publisher page changes

The publisher page has been adjusted. If a publisher:

  • has at least one publication series associated with it, and
  • has publications that are not in a publication series

then the software will display the number of pubs not in a publication series and link to a new Web page called "Publications not in a Pub. Series for Publisher: [publisher name]". See Festa for an example.

If the number of publications not in a publication series exceeds 500, the count will be displayed, but there will be no link to the new page. Instead the software will display a message similar to "8940 publications not in a publication series (too many to display)" -- see Tor for an example. Ahasuerus 23:53, 19 November 2016 (UTC)

I like this change; thanks for implementing!
Now that I've looked at a bunch of publisher records, I'm wondering if it might make sense to either place this at the top of the list (above the "Publication Series" header) or to leave it at the bottom but without a bullet and maybe a little white space to help differentiate it? It tends to blend into the list, especially when it is a link. Albinoflea 07:49, 22 November 2016 (UTC)
That's a good point. I have moved the link to the top of the Publication Series section. How does look now? Ahasuerus 21:50, 22 November 2016 (UTC)
Now that I have re-read your comment, I see that I misread it. You wrote "place this ... above the "Publication Series" header" while I read "place this ... below the "Publication Series" header". Sorry about that! However, before I do anything else, could you please review the current layout to see how well it works? Ahasuerus 21:53, 22 November 2016 (UTC)
No worries, I think I do prefer it at the top, and maybe it doesn't need to be above the "Publication Series" header, maybe just remove it from that unordered list so it stands out as being different... so instead of:
Publication series:
  • 867 publications not in a publication series (too many to display)
  • Alpha Science Fiction
  • Archway
something more like:
Publication series:
867 publications not in a publication series (too many to display)
  • Alpha Science Fiction
  • Archway
Albinoflea 21:15, 23 November 2016 (UTC)
It so happens that I was coding the latest patch while you were typing your response :)
After sleeping on it, I decided to make the link available on all publisher pages, the idea being that it can be useful to get an overview of a publisher's activity. Prior to this change, if a publisher published 10 books in 10 different years, you had to pull up 10 pages to see everything. Now you can see all of them on the same page, nicely sorted by year.
The latest patch also implemented additional quality of life enhancements: grammar fixes, a link from the new page back to the publisher page, and better sorting on the "publisher year" page. Ahasuerus 21:48, 23 November 2016 (UTC)
Will the patch take a while to implement? I am not seeing it yet (for example, on Tor). ···日本穣 · 投稿 · Talk to Nihonjoe 22:37, 23 November 2016 (UTC)
That's odd. I see "8941 publications not in a publication series (too many to display on one page)" between the line which says "Note: Other imprints: Starscape" and "Publication series:". Are you seeing something different? Ahasuerus 23:07, 23 November 2016 (UTC)
Oops, missed that. Is there a way to view 100-200 at a time? Basically show what it would if there weren't too many publications to display on one page? ···日本穣 · 投稿 · Talk to Nihonjoe 23:16, 23 November 2016 (UTC)
A timely question indeed! I have been slowly consolidating the logic behind our publication tables to ensure that they all had the same columns, headers, etc. I have one more table to consolidate, then I should be able to review/enhance the way paging is done. Unless I ran into unexpected issues, I should be able to add paging to this publication table as well. Ahasuerus 23:50, 23 November 2016 (UTC)
Awesome! ···日本穣 · 投稿 · Talk to Nihonjoe 00:04, 24 November 2016 (UTC)

(unindent) Looking good! Thanks! I find myself missing the "show covers" link but hopefully that will be making a reappearance if you're consolidating the display logic. Albinoflea 17:06, 24 November 2016 (UTC)

Could you please provide more details? I don't think I am aware of any recent changes to "Show Covers". There are two User Preferences, "Display cover images on Title pages" and "Display cover scan indicators on Title pages", which, AFAIK, are working correctly. Although, now that I am thinking of it, the latter should be clarified to add that it also controls whether "cover scan indicators" appear on search pages. Ahasuerus 17:42, 24 November 2016 (UTC)
"Display cover scan indicators on Title pages" has been changed to "Display cover scan indicators on Title and search pages". Ahasuerus 18:03, 24 November 2016 (UTC)
Ah, sorry, what I was trying to say was the newly generated pubs_not_in_series.cgi pages don't have the "show covers" links but pubseries.cgi pages have a full compliment of links: Show last year first • Sort by series number • Show covers
Clearly the "Sort by series number" link makes no sense on pubs_not_in_series.cgi but the other two links probably would serve a purpose; the first link might be changed to "show most recent year first" if the default sort order is already set to show last year first.Albinoflea 07:15, 27 November 2016 (UTC)
Oh, I see. Sure, FR 952 has been created. Ahasuerus 22:47, 27 November 2016 (UTC)

Patch - punctuation in author names

FYI, a new patch was installed a few minutes ago. It tweaked the way punctuation (apostrophes etc) is handled in author names. The changes were not supposed to affect user-experienced software behavior in any way. If you see anything unusual, please report your findings here. Ahasuerus 23:36, 20 November 2016 (UTC)

My Pending Edits changes

"My Pending Edits" has been changed to show the name of the moderator who has your submission(s) on hold. In addition, column names have been adjusted to be more accurate. Ahasuerus 00:36, 21 November 2016 (UTC)

Title/Publication Type values in Advanced Search

Advanced Search has been modified to treat Title Type and Publication Type values in a case-insensitive manner. For example, an Advanced Title Search on "Title Type is exactly Poem", which used to result in an error message, now produces the same results as an Advanced Title Search on "Title Type is exactly POEM". Ahasuerus 21:03, 21 November 2016 (UTC)

"Suspected Duplicate Authors" now available to all editors

The cleanup report "Suspected Duplicate Authors" is now available to all editors. The ability to "ignore" suspected duplicate pairs remains restricted. Ahasuerus 22:38, 21 November 2016 (UTC)

Gilbert Morris?

Would anyone be interested in fleshing out Gilbert Morris's biblio? According to Wikipedia, he wrote or co-wrote around 200 books prior to his death earlier this year. Only a few of his series were SF, so we'll have to be careful. Ahasuerus 01:54, 22 November 2016 (UTC)

Wiki cleanup - magazines

Most of the remaining magazines in the wiki cleanup section are like this one - series exists but not all magazines that are known to exist are added as stubs (or full records) -- although more than what is marked in the wiki is added in this case, there are still a lot of missing ones (see the grid). Should I add them as stubs (so someone can add content one day if they can find it) or just leave them as they are? I lean towards adding the stubs so at least we have the records but wanted to ask for the community opinions :) Anniemod 18:04, 22 November 2016 (UTC)

I think creating stubs is the better approach. It will preserve the data that we already have and make issue grids more useful/complete. Ahasuerus 18:29, 22 November 2016 (UTC)
That's my thinking as well (and that is what I had been doing with the fanzines with no series) but decided to check if that may be an overkill. I am seeing a lot of NewPub submissions in my future then :) Anyone opposing? Just checking before I start creating them. Anniemod 18:53, 22 November 2016 (UTC)
I'm presuming that this cleanup report is a moderator report. Doug H 16:09, 23 November 2016 (UTC)
I believe it is available to all users. See [1]. -- JLaTondre (talk) 17:32, 23 November 2016 (UTC)
Wiki cleanup reports (see the "Wiki Cleanup" section) are available to all editors. However, only moderators can delete Wiki pages. Once an editor transfers all relevant data from a Wiki page to the database, the next step is to add Template:Page transferred to the top of the page and wait for a moderator to delete it. Ahasuerus 17:35, 23 November 2016 (UTC)
Considering that I am not a moderator, I can confirm that the wiki cleanup reports are visible to all editors :) Anniemod 18:04, 23 November 2016 (UTC)

Patch: Unicode characters in URLs

The software has been changed to allow Unicode characters in URLs. In the past you had to use their encoded values in order to get past the validation logic. With the latest change the only remaining requirement is to have "http" or "https" as the first characters of the URL. Ahasuerus 23:04, 22 November 2016 (UTC)

Awesome! ···日本穣 · 投稿 · Talk to Nihonjoe 19:43, 23 November 2016 (UTC)

"Other" pub format - an example

Just an interesting example of what 'other' would be used for in a publication. From a review of four titles:

"These four "classics" of the genre are available once again in ASCII format on either 5.25" or 3.5" diskettes".
Doug H 16:03, 23 November 2016 (UTC)

Eliminating "sf"/"shortfiction" during editing

FR 937 "Eliminate 'sf'/shortfiction dropdown choice", which I created a couple of months ago, reads, in part:

In the Content section of NewPub/EditPub/AddPub/ClonePub forms, the "storylen" dropdown list is typically limited to four choices: "-", "shortstory", "novella", "novelette". However, sometimes a fifth choice, "shortfiction", appears. Also, when "-" is filed for a SHORTFICTION title, the software puts "sf" in the "storylen" field. [The 'sf' code and the 'shortfiction' value are unnecessary during editing because] the software already displays the word "shortfiction" for SHORTFICTION titles without a storylen code.

I plan to change the software to eliminate all appearances of "sf" and "shortfiction" in drop-down lists. The database will be simultaneously updated to remove all occurrences of "sf" from the "story length" field. Short fiction titles without a story length code will continue to be displayed as "shortfiction", so nothing will change as far as our users are concerned.

If there is anything that I may be overlooking and that may cause issues, please post your concerns here. Ahasuerus 00:13, 24 November 2016 (UTC)

Author Directory changes

Author Directory has been enhanced in a couple of ways:

  • The main table no longer displays invalid entries for transliterated author names
  • Lower level pages use the same table layout and paging/merge logic as Advanced Author Search

In addition, all Advanced Author Searches have been enhanced to use canonical names as secondary sort values. For example, if you request that author records be sorted by "family name", Advanced Author Search will sort records by "family name" and then sort them by canonical name within each "family name". Ahasuerus 23:08, 24 November 2016 (UTC)

2016-11-27 downtime

The server will be unavailable between 6pm and 6:05pm server (US Eastern) time. Ahasuerus 22:26, 27 November 2016 (UTC)

The server is back up. 'sf'/'shortfiction' is no longer used in "story length" field. I will be checking Help shortly to make sure that there are no references to it. SHORTFICTION titles without a "story length" value will continue to be displayed as "shortfiction". Ahasuerus 23:02, 27 November 2016 (UTC)
All references to 'sf' have been removed from Template:TitleFields:Length. I also rewrote the text for readability and clarity. It would be great if more eyeballs could review the changes. Ahasuerus 23:41, 27 November 2016 (UTC)
Shortstory should really be 2 words. Anniemod 03:27, 28 November 2016 (UTC)
Well, that's the way it's been displayed on all pages since day one. We'll need to change the software before we change Help :-) Ahasuerus 04:03, 28 November 2016 (UTC)
If we are trying to match the software exactly, then all 3 should start with small letters then as they are in the dropdown :) Anniemod 17:22, 28 November 2016 (UTC)
Good point, updated. Ahasuerus 18:57, 28 November 2016 (UTC)
Two more format things: Is the double star by design in front of the short fiction categories? It is inconsistent this way. And shouldn't shortstory/novella/novelette also be with small letters to match the drop down when you add a short story? Anniemod 19:08, 28 November 2016 (UTC)
Updated, thanks again! Ahasuerus 20:15, 28 November 2016 (UTC)
Looks good. :) Anniemod 21:52, 28 November 2016 (UTC)
And the omnibus introductory sentence took me a bit to understand. Maybe move it before the "other types" so it goes: Short fiction (start on a new line for that - so the first line is just the explanation of what it is), omnibus, others. And I would say "For omnibus, the value should be built in the following way" or something along these lines. Anniemod 03:27, 28 November 2016 (UTC)
Updated, thanks! Ahasuerus 04:03, 28 November 2016 (UTC)
Looks great! Anniemod 17:22, 28 November 2016 (UTC)

Wiki cleanup - publications - opinions needed

A lot of the wiki pages for publications look like this. Some of them even have pictures of the logos and whatnot. What should be done with them:

  • Add all the information from them to the publication notes (except when there are pictures - for them only the second option seems viable)
  • Link the publication to the wiki page in the notes (because publications do not have a handy place to add a link as all other types of records do)?
  • Something else?

Opinions? Anniemod 23:31, 28 November 2016 (UTC)

I believe almost all of these pages were created by Marc Kupper back in 2008. The last time we discussed them, Marc saw value in preserving the data. It may be too elaborate and detailed for the main database record, so I would be inclined to keep these Wiki pages "as is" and link to them from the Note field. Ahasuerus 02:15, 29 November 2016 (UTC)
Links it is then. With notifications to the PVs that I am adding them (the ones that want notifications for notes anyway). Any chance to add "Link" fields into Publications at some point as we have it for everything else? (it will be really useful for linking publisher pages, online versions of magazines, pages on other sites (Fantlib, SFBG and so on) and whatnot? Anniemod 02:22, 29 November 2016 (UTC)
At one point I proposed adding the standard repeatable "Web Pages" field to publication records. At the time, there was no consensus re: its desirability, but please feel free to propose it again if you believe that the functionality would be desirable. Ahasuerus 02:43, 29 November 2016 (UTC)
I just did, didn't I? :) Especially now with removing the wiki connection so you cannot stick your links there? Or do you want me to start a new topic here? Anniemod 03:09, 29 November 2016 (UTC)
I think it would be better to start a new topic to make sure that all editors see it. Ahasuerus 04:00, 29 November 2016 (UTC)

A new cleanup report -- "Empty HREFs in Publication Notes"

A new cleanup report, Empty HREFs in Publication Notes, has been deployed. Once the nightly process runs, all editors will be able view the data. As of this morning there were 28 publications with empty HREF attributes in Notes. Ahasuerus 02:12, 29 November 2016 (UTC)

Corrected. Chavey 12:53, 29 November 2016 (UTC)
Thanks! Ahasuerus 15:57, 29 November 2016 (UTC)

Change proposal - add links fields to publications

As we are removing the wiki connections and more and more specific editions have their own web pages (at publisher's websites), not to mention magazines and fanzines, it seems to make sense to have the Web Page fields on publications the same way we have them on pretty much anything else. Any opinions? Anniemod 04:17, 29 November 2016 (UTC)

I think that would be a good idea. ···日本穣 · 投稿 · Talk to Nihonjoe 06:16, 29 November 2016 (UTC)
I don't know if this would be worthwile: publishers do fold or revamp / migrate their websites, meaning that the links will become obsolete after some time. Stonecreek 07:12, 29 November 2016 (UTC)
True - but there are stable links also - FantLab for Russian publications, SFBG for Bulgarian ones, (more for different languages), our own Wiki if there are details that are too much for the details page. And some publishers do keep stable links for years. Then there are magazines and fanzines archived all over the place - now the only option for all of these is the notes field (and the title record is not an option because it is on the year level). If we are worried about links that move/stop existing, we might as well remove all links from all kind of entries - we just went through cleanup of IMDB links for example because they changed their format. Just thinking aloud. Anniemod 07:29, 29 November 2016 (UTC)
Yes, but it will still be a problem to maintain the links: if we link one publication we can't exclude a link submitted by anyone. This would end in a pandemonium of unsupported links. Plus: I have experienced the collapse of sites that I personally would have thought stable. Stonecreek 07:56, 29 November 2016 (UTC)
How is that different from having links for Publishers and Titles? We already have those. And having them won't mean "always use them" - the ones on the titles are not used that much either. Anniemod 08:00, 29 November 2016 (UTC)
I often run into dead links, which I can then use to go to the Wayback Machine to see what used to be there. So having a specific dead URL is still a very useful piece of information. And maybe someday we'll even have an "automated system" to convert any such dead link into a Wayback link. Chavey 08:15, 29 November 2016 (UTC)
It is the sheer amount of links that would have to be maintained that's different (if the links aren't used that often why bother to add them anyway?). Maybe it'd be better to automatically add a link to a publisher's site, provided we have one and it'd be easily installed. Stonecreek 09:39, 29 November 2016 (UTC)
Why do you expect more links than we have for titles now? Most of the added links will be there because it contains information and/or is built for this specific publication. Publisher site was just an example above. I am in the process of adding a lot of links to our Wiki pages into publications (as part of the wiki cleanup - too much data to move into the notes, so it needs to stay in the wiki and to be linked) - which made me wonder why we do not have links here. Same with the fanzines and magazines I had been working on - all links need to go into the Notes field now - which is inconsistent with any other record we have here. Anniemod 09:50, 29 November 2016 (UTC)
The title links are mostly to wikipedia, which hopefully is much more stable than any other site maintained by a publisher. I'd think that one of the reasons that we don't supply links to individual publications is the instability of other sites. Stonecreek 10:57, 29 November 2016 (UTC)
I think it would be a nice feature for (perma)links to LCCN, OCLC, National Libraries etc. We now have thousands of links in the notefield. --Willem 11:17, 29 November 2016 (UTC)
This'd be ideally dealt with in the tools (found on left side), as is already for OCLC and others. Stonecreek 11:40, 29 November 2016 (UTC)
There is a Feature Request to add support for "external identifiers" which will be linked to by number (BLIC, LCCN, ASIN, OCLC, etc.) Fixer has been begging me to implement this functionality for some time now, so I will probably get to it sooner rather than later.
Having said that, there will always be unstructured links to third party sites which will require full URLs instead of numbers. I also agree with Darrah re: the Wayback Machine -- a dead link is often more useful than no link at all. We already capture third party URLs in Notes, so it's just a question of how we want to organize them; I find that a standard repeatable field is easier to use and more maintainable than HTML in Notes. Ahasuerus 13:59, 29 November 2016 (UTC)
FR 957 has been created. It mentions that "[i]t is suggested that this functionality should be implemented in conjunction with the "Support for external identifiers" FR in order to minimaize the amount of rework that will be required when moving links from Notes to the newly implemented fields." Ahasuerus 03:31, 1 December 2016 (UTC)

Publication Series with not all titles linked

Hi, I'm not in a position to do editing for ISFDB right now, but this may be something one of you would like to change:

[Series: Fiction River]

[unlinked titles]

Special Edition: Crime and Alchemy and Steam should probably be linked to the main series?

Also Pulse Pounders is linked to the main series with the Publication Series name tacked on the front; the rest of the books in the series do not have that.

Thanks, JJ 05:17, 29 November 2016 (UTC)

I've submitted updates and corrections for everything. ···日本穣 · 投稿 · Talk to Nihonjoe 06:16, 29 November 2016 (UTC)

Should these be united under a global "Fiction River" universe?

JJ 23:40, 22 December 2016 (UTC)

"Clear Form" buttons?

Does anyone use the "Clear Form" buttons that some data entry forms display at the bottom of the page? I have only clicked them a few times when I meant to click "Submit Changed Data" instead. Needless to say, the results were not what I wanted.

If my experience is representative, we may want to remove these buttons to help minimize editor frustration. Ahasuerus 18:07, 29 November 2016 (UTC)

We have "Clear Form" buttons somewhere? That should tell you how much I will miss them. Although that may explain something happening one of the evening when I though that my browser is getting crazy on me and reloading and losing content... :) Anniemod 19:19, 29 November 2016 (UTC)
Title Editor, Publication Editor, Add Variant Title, and Add Publication support this functionality. Ahasuerus 19:24, 29 November 2016 (UTC)
The first two explain my "browser" issues :) I tend to not even look at the buttons on those two - so even if I saw the clear buttons, I never used them and I had forgotten all about them. I do not think I had ever used Add Variant (I still cannot figure out a usecase where it helps reduce the number of edits) or Add Publication(I just clone and clean the differences even when there are a lot). Anniemod 20:07, 29 November 2016 (UTC)
I can't really imagine ever using "Clear Form" either. --Vasha 20:57, 29 November 2016 (UTC)
I've never used it, but I always assumed it cleared the form which I never imagined a use for. Having just tried it, if kept, it should be renamed to "Reset Form" which is a clearer description of what it does. I have had a use for that, but canceling the edit and starting over (which I've done in the past) is just as easy for as infrequently as it is needed. I'd be fine if it's removed. -- JLaTondre (talk) 23:27, 29 November 2016 (UTC)
Thanks, FR 956 has been created. Ahasuerus 02:57, 1 December 2016 (UTC)
Done. Ahasuerus 03:04, 1 December 2016 (UTC)

Changing "Non-Genre" and "Graphic Format" to checkboxes?

The Title Editor page contains four fields which let editors select a value from a drop-down list. Two of them, "Language" and "Title Type", are OK as is. The other two, "Non-Genre" and "Graphic Format", have drop-down lists which are limited to "No" and "Yes". I propose changing them to check-boxes. They would be similar to what we use on the User Preferences page and hopefully make the page cleaner, especially if we add more "Yes/No" choices in the future. For example, the way the software works right now, you can't use "jvn" or "nvz" in the "Storylen" field if the title type is SHORTFICTION. There is a feature request to create additional fields for these values, which will increase the number of "Yes/No" drop-down boxes. Ahasuerus 18:23, 29 November 2016 (UTC)

Yes please. :) I would also say that "jvn" and "novelization" probably should also be checkboxes that may populate length if we really want them to but are clearer on their own. Anniemod 18:49, 29 November 2016 (UTC)
I like this idea. ···日本穣 · 投稿 · Talk to Nihonjoe 19:15, 29 November 2016 (UTC)
I agree on all counts. --Vasha 21:17, 29 November 2016 (UTC)
Agreed. -- JLaTondre (talk) 23:52, 29 November 2016 (UTC)
Done. Unfortunately, the way most browsers treat disabled HTML check-boxes is somewhat iffy. You can see the odd coloration if you try to edit an INTERIORART or COVERART title. The "Graphic Format" check-box will be disabled, but the difference may not be apparent. Ahasuerus 01:15, 1 December 2016 (UTC)
It turns out that I forgot to update the "New Publication" form, which caused all NewPub submissions to set these flags. The bug has been fixed and the data has been corrected. Sorry about that! Ahasuerus 13:47, 1 December 2016 (UTC)
Speaking of drop-down lists, how come the options for story lengths are in the order novella-shortstory-novelette? shortstory is the commonest and should be at the top. --Vasha 06:11, 1 December 2016 (UTC)
I am not sure whether the current order, which was implemented in 2004 when I was on hiatus, was an attempt at alphabetizing the "story length" values or whether it was random. Once the code has been rewritten and streamlined, it should be easy to change the order. Ahasuerus 13:46, 1 December 2016 (UTC)
That'll be good, thanks. --Vasha 16:00, 1 December 2016 (UTC)

(unindent) The help pages for those two need changing -- they still reference dropdown boxes. Anniemod 05:59, 3 December 2016 (UTC)

Updated, thanks. Ahasuerus 23:58, 3 December 2016 (UTC)

Splitting edit forms?

Some of our data entry forms let you do multiple things. It seemed like a good idea at the time, but it's been my experience that it can confuse new editors. Here are the main offenders:

  • "Make/Remove a Pseudonym" lets you:
    • create a new pseudonym, OR
    • delete an existing one
  • "Make This Title a Variant Title or Pseudonymous Work" lets you:
    • turn the current title into a variant of an existing titles, OR
    • turn the current title into a variant of a new title, OR
    • break the current variant relationship
  • "Import Content" lets you:
    • import all titles from another publication, OR
    • import one or more explicitly specified titles

The advantage of the current system is that it limits the number of options in the navigation bar on the left. However, its disadvantages may outweigh its advantages. I am too used to the current system to be a good judge of how intuitive it is, so I'd like to ask other editors, especially relatively recent editors, whether the current system was confusing when they started editing here. Ahasuerus 18:39, 29 November 2016 (UTC)

I am not sure I agree with you about Import Content. It kinda makes sense to stay together - the page is small and clear enough and the two options are pretty clearly separated. If anything, that is one of the most intuitive actions around here -- once you remember it exists :) Anniemod 18:53, 29 November 2016 (UTC)
What prompted me to ask this question was a fairly experienced editor recently mentioning how tedious it was to import individual titles into a publication. It turned out that he didn't realize what the bottom half of the page was for. Ahasuerus 19:02, 29 November 2016 (UTC)
Ah, I do not remember if someone pointed it to me or if I figured it out but I still think it is one of the most intuitive pages for me. I never get confused on that one (some of the others still require me to think a bit on what I am trying to do really). Your mileage can vary of course. Anniemod 19:17, 29 November 2016 (UTC)
The Make/Remove ones, I agree, can get a bit confusing - not to mention that the design of the Make pseudonym that allows ID or a name is confusing as well (ask me how often I was pasting the id in the wrong field or how long it took me to realize that if I have the ID, I do not need the name as well? Finding an ID is easy and fast - why do we have the ability to use a name? :) . Anniemod 18:53, 29 November 2016 (UTC)
I believe you are the first editor to say "Finding an ID is easy and fast - why do we have the ability to use a name?" Everyone else who has commented on this data entry form over the years said something like "I don't think I have ever used author IDs. Why do we support them here?" :-) Ahasuerus 18:59, 29 November 2016 (UTC)
Well... with the DB becoming international, it should be self explanatory now why we need them. :) I am surprised though - the system is complicated enough without the possibility of a misspelling to attempt to create a wrong pseudonym. But then it may be my IT background kicking in and demanding IDs. Or the years of editing non-latin DBs and sites :) Anniemod 19:17, 29 November 2016 (UTC)
As a recent editor, I didn't know until this moment that "Make/Remove a Pseudonym" existed. One of my biggest sources of learning has been simply finding all the things I could and should do. For that reason, I think having a long, long list of similarly-named tasks would be a hindrance; I'd rather have them grouped together, similar tasks combined in one page.
I agree that "Import Content" is good and would only be weakened by putting the two functions on separate pages. As for varianting, there's a case to be made for separating the making/breaking of relationships between existing titles, on the one hand, and creating a new variant title, on the other hand. I find that the filled in form at the bottom of that page attracts my eye and draws me to click on the button underneath it even when I entered an ID in the top section. I've done that a zillion times, though not recently (well, only once recently...) I actually think that page is confusing. Maybe a two-stage process? Enter the ID you want to link to; if there is none, "click here" to bring up the form for a new one. --Vasha 19:32, 29 November 2016 (UTC)
Instead of new pages, perhaps look at re-laying out the existing ones. Import content, in particular, would be a good case for this. Separate the sections with a bit more space and add a title to each section to make it clearer what each one is for. -- JLaTondre (talk) 23:59, 29 November 2016 (UTC)
Thanks, FR 955 has been created. Ahasuerus 01:27, 1 December 2016 (UTC)

Link to pending edits should be on all pages?

While you're discussing changing the interface, can I request that the links to Pending and Recent Edits be on all pages, just as My Messages is? Sometimes I submit a change and I immediately want to go cancel it, or check that it isn't a duplicate of one I previously submitted; so the link to Pending ought to be on the "submitted" page, and for that matter, everywhere. --Vasha 02:08, 30 November 2016 (UTC)

I agree. It would be nice to always have the "Logged In As" section visible (with all the user-specific "My xxx" links in it). After submitting anything, a person has to go to the Home Page to get that section to reappear. ···日本穣 · 投稿 · Talk to Nihonjoe 18:25, 30 November 2016 (UTC)
Agree. And the "Cleanup Reports" link. It is very annoying to try to get back to it after a submission when I forget to open a new tab or when I am working from my phone :) Anniemod 18:58, 30 November 2016 (UTC)
Thanks for the feedback! There are some limitations due to the way the software is structured, but what you are describing should be doable. FR 953 has been created. Ahasuerus 19:28, 30 November 2016 (UTC)
The requested changes have been made. The "My..." links are now displayed on all pages. "Cleanup Reports" has been moved to the bottom of the "Other Pages" section and should also appear on all pages. Ahasuerus 23:39, 30 November 2016 (UTC)
Speedy delivery! Thanks! ···日本穣 · 投稿 · Talk to Nihonjoe 23:44, 30 November 2016 (UTC)

L. M. Montgomery's novels?

We list two novels written by the famous children's author Lucy Maud Montgomery who is usually credited as "L. M. Montgomery". As near as I can tell, one of the novels, Jane of Lantern Hill, contains no speculative elements. The other one, Magic for Marigold, apparently includes references to "childhood magic", basically daydreaming.

Would anyone with first hand knowledge of these novels be able to clarify whether they have any speculative elements? If not, then we may want to delete them since she is "below the threshold". We may also want to change her canonical name to "L. M. Montgomery". Ahasuerus 23:31, 30 November 2016 (UTC)

Magic for Marigold has an imaginary friend and a lot of daydreams but there is no way to stretch it to be able to call it a fairy tale, let alone speculative fiction. Jane of Lantern Hill doesn't even have that - no speculative elements there (I don't even remember daydreaming on any scale). And I agree that the canonical name should be the L. M. variant - it is actually considered her pen name :) Anniemod 23:43, 30 November 2016 (UTC)
Looking through the links on L. M. Montgomery's page led me to the anthology Saved by the Belle, a book of stories about women that has exactly one speculative entry ("The Shell of Sense" by Olivia Howard Dunbar); although a couple others are otherwise in the DB due to appearing in anthologies of adventure and suspense. Should I remove all the stories except "The Shell of Sense" from the contents? --Vasha 01:03, 1 December 2016 (UTC)
Checking submission history, I see that this collection was fleshed out by Darrah Chavey. We'll need to check with him to see what he knows about it. Ahasuerus 01:34, 1 December 2016 (UTC)

Name for the "Contents notes for omnibus titles" field?

I am ready to start working on FR 163, "Create new Title fields to move storylen values to". I am not going to add support for "suggested age range" for juvenile titles, at least at this time, but otherwise I plan to do exactly what the FR requested. We will have three new fields for:

  • novelizations (a check-box)
  • juvenile titles (a check-box)
  • contents notes for omnibus titles

The two check-boxes will have self-explanatory names, but I am not sure what we want to call the "contents notes for omnibus titles" field. Once a field name has been established, it's somewhat time-consuming to change it, so it would be nice to get it right the first time. Not only should the name be clear, but ideally it should also be flexible in case we decide to expand its use later, e.g. to cover collections. Any ideas? Ahasuerus 03:26, 1 December 2016 (UTC)

Why not just call it Content(s)? Or Content Expression if we want it more descriptive? Anniemod 05:48, 1 December 2016 (UTC)
OK, "Contents" may work. It's the same as the name of the "Contents" section in New/Edit/Clone/Add Publication forms, but I doubt it will cause problems. Ahasuerus 13:42, 1 December 2016 (UTC)

Novel contents: is there a way to...

I have been entering the volumes of Carlos Fuentes's Obras reunidas (Collected Works), most of which are omnibuses. One of them, Volume VI, though, is a single novel, accompanied by copious editorial materials, and here's the problem: The title of the volume is Obras reunidas VI: Nuevo mundo narrativo. Terra nostra. The title of the novel, which begins on page 29, is Terra nostra. Given that the record has the title type NOVEL, is there any way I can get the Contents to display correctly? Currently the NOVEL listed in the contents has the title of the volume. It probably wouldn't be a good idea to import a record for the novel alone with the correct title... --Vasha 16:54, 1 December 2016 (UTC)

The way you had done it is how it is usually done - see Complete Writings of Oscar Wilde, vol. X: Dorian Gray for example. The Variant connection shows the actual name so it looks fine to me. Adding notes in the publication is probably your best bet :) Anniemod 17:31, 1 December 2016 (UTC)
Yeah, you're right, the way it is now is 100% comprehensible, so that's fine... it just offends my sense of order and aesthetics! :-) --Vasha 17:47, 1 December 2016 (UTC)
Yeah, I know. :) Now - technically you can import the properly named novel and remove the one with the ugly name. But that will make the publication and title titles different and as the way it looks now is clear enough, I am not sure that it is worth it. Plus it will show on the report for the mismatch and more likely than not I will come to your page to ask you which one you like more because the difference is not worth the exception. :) By the way - you may want to edit your publication to put the page number for the novel into the entry - you cannot do that when you are adding but once it is accepted, you can (so it goes in the proper place in the table of content).:) Anniemod 18:03, 1 December 2016 (UTC)
If I merged this with the title Terra nostra instead of varianting, I would get the result I wanted at the cost of the title and publication records having different titles. As you said, that is one of those things that is "just not done" so I think better not to. Is there some technical thing that this would mess up, too? I have seen some titles that do have publications with somewhat different titles, usually versions with and without a subtitle. --Vasha 18:17, 1 December 2016 (UTC)
Yes, result will be the same (and with less edits) :) No, it won't break anything, it will just show on one of the cleanup reports(that I had been working very hard to clear - thus my half joke above about me coming to ask you which one you want to keep:) ). But it can be ignored by a moderator in case there is a legitimate reason for the difference - at which case it won't be a problem at all. Now - subtitles are a special case - there is a suppression of the flags when subtitles are involved (that is why there is a standard for the subtitle position and so on - so they can be recognized.) If you have two different subtitles on the pub and title, it gets flagged but when one of them has none. Not consistently implemented - in some cases we have the title without allowing all pubs to stay under it cleanly; in some we have variants for US and UK separate ones. It comes down to conventions, preferences and timing I guess. Anniemod 18:32, 1 December 2016 (UTC)
By the way - if you really think that it will be better to have the novel name properly set inside (and considering that you have the content inside, it does make sense), just submit the merge. And when tomorrow it shows on the report, I will remember to ask a moderator to ignore it :) Anniemod 18:36, 1 December 2016 (UTC)
I will wait until tomorrow to see if anyone else objects. If they don't, I'll submit the merge. --Vasha 18:45, 1 December 2016 (UTC)
On second thought, no I won't. Better to have a separate title record for that volume so (for example) it can be found on a search of titles. --Vasha 19:01, 1 December 2016 (UTC)
Every action has a side effect :) Anniemod 21:17, 1 December 2016 (UTC)

Bug with REVIEWs/INTERVIEWs and non-genre/graphic format check-boxes

There is a bug in the software that handles REVIEWs/INTERVIEWs and non-genre/graphic format check-boxes. I expect to fix it shortly. I will also fix the affected REVIEW/INTERVIEW titles. Ahasuerus 20:26, 1 December 2016 (UTC)

The software and the data have been fixed. Ahasuerus 20:45, 1 December 2016 (UTC)

Fixer's Future

(moved from the Help Desk)

Between the increased number of SF books being published (how dare they!) and Fixer's data acquisition logic becoming better, my workload has jumped significantly in the last few years.

Fixer used to find just a few thousand new ISBNs per month and it took me a week+ to process them. Now he finds anywhere between 6,000 and 8,000 ISBNs depending on the month. It takes me more than 2 weeks to process them, sometimes closer to 3 weeks. The workload is becoming unmanageable and I am not getting any younger either (8-10 hours a day is pretty much my limit now.)

We'll need to do something about this issue if we want development to continue at a reasonable rate. I have been toying with different procedural and software-based solutions, but they all have different flaws. I am kind of hoping that your work on publishers may serve as a template for a more permanent solution. Ahasuerus 01:51, 1 December 2016 (UTC)

Single threaded processes are bad processes. That relies on people being available monthly - and despite good intentions, life happens. So how about delegating part of the work in a slightly different way? I do understand that Fixer itself cannot be delegated but why not delegate some of the manual checks and then have Fixer (or another robot) do the Add/ClonePub records. My understanding is that every record that Fixer adds is manually inspected to verify that it is in scope and to fix the things he is not good at (determining type for example). So enlist the rest of the editors to help with the manual checks: once Fixer has its catch, get it to parse and populate tables/sections (will explain the plural in a second) with all needed elements for Clone/Add and post them so people can help fill the missing details and get the "is it a real book and is it ours" check. Add a last column "ready for adding" and get the robot to add based on that column
This way you eliminate the longest work by far in working through a publisher/list of ISBNs from the editors' tasks and you have data that can be added automatically. Editors will mark the book as chapbook, novel, collection or whatever it is properly, mark the cover artist if known and so on - as long as the table shows the empty spaces where Fixer does not know and have the data populated for the ones it can so they can be verified, that should be easy enough. Different types will need somewhat different follow-up work - novels and non-fiction can go directly (no content to add after that). Same is valid for chapbooks that have only one story and the name of the chapbook and story are the same. Collections/omnibus/anthologies and annoying chapbooks where the story has a different name are all special cases but they can be handled the old way or something new can start getting developed. Even if just the novels and the easy chapbooks and the non-fiction gets handled this way, it will eat a chunk of the work.
The multiple tables/sections are to allow different editors to claim a section so they can work on it without stopping on each other's toes (and we have the nice way to sign in wiki). If you have time and want to process the old way, claim the group for you and do it - or do not post all of them to start with.
Am I missing something that will make that non-workable? Anniemod 02:41, 1 December 2016 (UTC)
I have considered using Wiki pages to facilitate Fixer processing, but before we get any further, let me post a link to this explanation of how Fixer works and another link to the associated moderator Help section. Once we are on the same page, we can discuss which steps could be adjusted/farmed out to other editors.
I should also point out that the original plan was that I would process Fixer's queues and supervise submission creation, leaving submission approval to other moderators. Unfortunately, experience shows that Fixer's submissions require a significant amount of manual TLC, which moderators are not always in a position to provide. You have to research misspelled author names, omitted/variant publishers/imprints, series, publication series, bindings (is it a pb or a tp?) and so on. Moderators are busy people and in many cases they don't have the time needed to investigate these issues thoroughly. Ahasuerus 00:29, 2 December 2016 (UTC)
After we started talking about Fixer, I went and read all I could find (including those two). I just reread them again though and I think we are on the same page (except for non-documented stuff I do not know :) ).
That's exactly my point though - make the robot (Fixer or Fixer2.0 or whatever) submissions easy to moderate. If you farm the verification, data cleanup and preparation out, then moderators can approve the submissions from the robot with no major verifications -- the problematic ones that cannot be found won't show up and if a book need something special to be found, the notes for it can be in the wiki as well. Include the cleaning editor name if you want so if there is a bad batch of data, they are foundable after the first few bad ones and help the editor understand what they are doing wrong. It will take awhile at the start I suspect but it will get streamlined sooner or later. And allowing a data cleaner to add a flag saying "manual/more details needed" can exclude anything that needs to be added but is just too... complicated for the automation or that they cannot figure out how to clean properly. I have no idea how many of the 6000/8000 are "easy" short of basic cleanup but if it is more than half, I would be surprised. All those checks already happen - except that you are the only one doing them...
Let me give you an example - when I am adding a book, I need to find its Amazon cover link (click on it, clean the field, run it in a browser window to be sure I did not misspell it and then paste in the field. For the Publisher - copy the string if I do not know it already, search in the DB to see if we have a record, get the proper name. And so on. If the list posted for cleanup uses automation to pull the picture URL so you need just to verify, pull the publisher (and flag the ones that do not exist in ISFDB?) and so on - basically fill as much as it can in the tables, it becomes a verification work with less copy/paste unless if it is needed... And if the parser does not work properly and dumps all in one field? Well - it can be moved around from whoever is clearing for addition.
I am not even trying to find a way to automate everything -- it is about getting enough titles out from the queues and finding more automated ways to do things so the queues are manageable. And that same process will be reusable for lower priority queues as well... Anniemod 01:51, 2 December 2016 (UTC)
Why not run the Fixer processing under cleanup reports? Put a series of okay/reject checkboxes next to each manual process. If not rejected, or fully edited, the title reappears in the cleanup report tagged, e.g., 1/6, 3/6, etc., in ascending order. When 6/6 is reached it either goes to the submission queue or is edited and approved. Editors starting with new Fixer submissions could do the tasks they find the most interesting first, then return later to complete the rest.--Rkihara 16:28, 2 December 2016 (UTC)
I am not 100% sure that I understand the proposal correctly, but it looks like you are referring to (some of) the first 9 steps of the Fixer processing. I am afraid they can't be delegated to other editors. I have updated Fixer's User page to explain that "The software known as "Fixer" resides on a development server which is different from the main ISFDB server. It can't be moved to the main server without a complete rewrite due to software compatibility issues." Ahasuerus 16:45, 2 December 2016 (UTC)

(unindent) I have further clarified Fixer's logic on his User page. The important things to note are that steps 1-10:

  • have to be run by me because they occur on the development server
  • have been highly optimized over the years

Our current problem is with step 11:

Moderators review and approve submissions created using Fixer's account. The robot maintainer reviews and approves submissions created using his account. See this Help section for a discussion of the challenges associated with processing robotic submissions.

Alas, processing Fixer-generated submissions is the most labor intensive and time-consuming step.

The way I see it, Fixer performs the following high level tasks:

  1. Find target ISBNs
  2. Find detailed bibliographic information for each target ISBN
  3. Build ISFDB-compliant submissions and add them to the ISFDB submission queue using the Web API

Each task is valuable since it saves editors a lot of time. I would like to preserve this functionality if at all possible.

The biggest problem with adding Fixer-built records to Wiki pages -- instead of building submissions and adding them to the ISFDB submission queue -- is that it forces editors to create submissions manually, which is time-consuming. It also makes it much harder to keep track of what has been rejected vs. submitted, which Fixer needs to know in order to avoid creating duplicate submissions.

After reviewing Annie's and Ron's responses, I am thinking that perhaps the best compromise solution would be something like the following:

  1. Fixer adds a submission to the main ISFDB submission queue
  2. A moderator clicks the "Approve" button
  3. The software adds the new record to the database as per the current process
  4. The software recognizes that the approved submission was generated by a robot (in this case Fixer) and adds the ID of the newly created publication to a special cleanup report
  5. All editors have access to the new cleanup report. An editor can put one or more publication IDs "on hold" the way moderators can put submissions on hold.
  6. Once the editor has massaged the "held" publication record to his or her satisfaction, he or she removes the publication from the cleanup report.

If we adopt this approach, we will need to think of a way to ensure that new editors do not accidentally stumble on this functionality and mess things up due to inexperience. Perhaps we could limit access to this cleanup report to editors with more than a certain number (1,000?) edits? Ahasuerus 17:11, 2 December 2016 (UTC)

Maybe total edits to New Pub+Pub Update>1000?--Rkihara 17:28, 2 December 2016 (UTC)
I don't have that many from those two categories I think :) Maybe a waiver if you have a certain number overall? There are legitimate cases where you know what you are doing but you had not added or updated too many new publications. Now I am back to reading the whole thing more carefully - comments to follow:) Anniemod 18:22, 2 December 2016 (UTC)
I used the proposed number, but narrowed down to the two categories, at 200-250 edits you pretty much know what you're doing.--Rkihara 20:27, 2 December 2016 (UTC)
BTW, at this time the list of top contributors is a raw HTML page generated by the nightly process. The only way to determine how many edits of different types an editor is responsible for is to parse the HTML. We'll need to rewrite the logic to put this data into the database. Luckily, it shouldn't take long. Ahasuerus 20:41, 2 December 2016 (UTC)
Unless I'm missing something, this is parsed out on the "Stats" page.--Rkihara 21:51, 2 December 2016 (UTC)
Our "stats" pages and the cleanup reports are regenerated nightly. However, there is a difference between the way the former and the latter are handled. All cleanup data is put in a proper database table, which is used by our cleanup reports during the day. On the other hand, the "stats" data is formatted as HTML tables and then dumped to text files. When you access one of the "stats" pages, the software simply reads in the data from the appropriate text file and displays it as a Web page.
What this means is that if we want to know how many approved edits an editor has to his or her credit, we need to open the "stats" file and parse the data out of the HTML table. It's not hard, just ugly. It can also cause errors later if the layout of the HTML tables ever changes. Alternatively, we can just count the number of approved submissions in the submission table, which is more resource-intensive. Ideally, we'll simply rewrite nightly processing and make it store the "stats" data in the database. Have no fear, one way or another we'll get it done :-) Ahasuerus 22:29, 2 December 2016 (UTC)
So basically you want to have the Fixer output always approved and THEN fixed instead of cleaning the data before addition? I suspect that this will be easier to implement in the short term but I still would like the other idea more (clean beforehand, then have a robot create the submissions from it - by basically removing the 3rd action from Fixer and giving it to another robot. I do not want to shift the creation of the newSub to the editors - just the cleanup of the data:) And maybe it will be a two step process and a post-addition cleanup is the way to start. Anniemod 18:29, 2 December 2016 (UTC)
What my idea was (and still is) is to inject the review between these two steps:
*Find detailed bibliographic information for each target ISBN
*Build ISFDB-compliant submissions and add them to the ISFDB submission queue using the Web API
Fixer finds all it can but instead of posting the submission, it creates a list somewhere (new UI or wiki) where someone can do the verifications before it hits the queue. Once that is done, get Fixer (or another robot) to use the cleaned data to post the submission. Wiki is the technology we have here. But it may as well be an "updateable record" where Fixer creates the submission but does not submit it and instead puts it a list that editors can get from, massage and send out when all is verified... In all cases that will reduce the work needed during the moderation, shifting the work ahead of time and allowing more people to help... I know that means more development but that will make it a lot more manageable in the long run. Anniemod 18:42, 2 December 2016 (UTC)
I see. I think there may be a way to do what you are trying to accomplish without creating new tools.
At the moment all submissions are put in the ISFDB submission table. Each submission can be in one of the following states:
  • New (and optionally "On Hold")
  • In Progress (aka "Errored Out" if it remains in this state indefinitely)
  • Approved
  • Rejected
We could add another submission state. Let's call it "Automated" for now. "Automated" submissions will not appear on the "New Submissions" page which moderators have access to. Instead they will appear on a separate Web page, which will be open to a subset of experienced editors. The page will display a list of all "Automated" submissions with an "Edit" button next to each.
When an editor clicks on the "Edit" button, two things will happen. First, the submission will be put on hold, which will prevent other editors from viewing or editing it. Second, the body of the submission will be loaded in the "New Publication" edit form. Once the editor has massaged the data and is satisfied that everything looks OK, he or she will click "Submit". The submission process will do the following:
  • Create a regular new submission independent of the original Fixer-generated one
  • Optionally add a "Note to Moderator" to the new submission. It may say something like "The original data was compiled by [robot name] and was modified by editor [user name] prior to submission".
  • Change the state of the original Fixer-generated submission from "Automated" to "Processed" or some such.
How does it sound? Ahasuerus 19:24, 2 December 2016 (UTC)
P.S. In addition, editors will need to be able to remove their holds and to mark "Automated" submissions as "deletion requested". Ahasuerus 19:33, 2 December 2016 (UTC)
I like that plan a lot -- it clears the submission queue from barely identified issues, it clears your time from the need to inspect each and every request and it allows more people to try to help.
And if Fixer messed up and started a NewPub instead of AddPub for something, the editor can add a moderator note "to be varianted under <ID>" or "to be merged with <ID>" so the handling moderator can do that immediately after approval. The special case where it is AddPub under the wrong title will need to either go the "deletion and manual add" or allow it throw and ask for an unmerge and followup merge/variant". Or alternatively this new thing may have a button to allow conversion from AddPub (requires parent ID) to NewPub and vice versa? Or replace the parent title when Fixer get a bit confused where a title belongs. Anniemod 19:54, 2 December 2016 (UTC)
If we decide to go with this approach, we'll probably implement it for NewPubs first since they take much longer to process. Once we are confident that things are working smoothly, we can add support for AddPubs. Ahasuerus 20:00, 2 December 2016 (UTC)
I was thinking aloud on what else may need changing while cleaning up a request. :) Small steps are better than no steps at all. Anniemod 20:03, 2 December 2016 (UTC)
As a general rule incremental changes tend to be safer. There are times when you can't avoid drastic changes, but the risk tends be high. Luckily, all we have is a single server, so we can deploy hundreds of minor patches without having to worry about patch management. Ahasuerus 20:36, 2 December 2016 (UTC)
True that - I wish it was possible in my day job as well. :) Anniemod 20:44, 2 December 2016 (UTC)

(unindent) I have come up with a design document for the proposed change. It involves a bit more than what we have discussed so far, but it looks doable. I will set other things aside and start working on it tomorrow. Thanks for the feedback! Ahasuerus 00:00, 4 December 2016 (UTC)

Back to the eligible editors - can you set up another security flag on ID's? Then it's a one-time load based on whatever criteria you want and infrequent updates thereafter? Doug H 20:05, 4 December 2016 (UTC)
Let me make sure that I understand the proposal correctly. Is the idea to explicitly give individual editors permission to access automated submissions? If so, then yes, it's possible, but it would involve considerably more work than the process described above. I think it should be reasonably safe to use the number of approved edits this way since all submissions will be subject moderator review. Ahasuerus 23:54, 4 December 2016 (UTC)
The discussion indicated to me that eligibility criteria were a best guess. Incorporating the criteria in the code does not allow for exceptions - either good editors or bad ones. And it ties a security attribute to a set of measures that may change, e.g. I saw a count of approved edits, but not a count of disapproved edits or any time factor. I was just wondering if a degree of separation could be achieved at little or no cost. Doug H 13:40, 5 December 2016 (UTC)
At the moment we use the standard MediaWiki software, which runs our Wiki, to handle almost all user management tasks. This includes account creation, logging on/off and moderator privileges. In addition, there are a couple of places in the software where we basically say "Restrict this functionality to users number 12345 and 67890". It is not very elegant, but it gets the job done as long as the number of affected users is low.
Upon reflection, you raise a valid question. There is a difference between being able to enter the book in your hands using Help as your guide and being able to work with secondary sources which present additional challenges. Perhaps we could start by limiting access to automated submissions to a subset of editors and then slowly expand it. Ahasuerus 18:26, 5 December 2016 (UTC)

Chinese book help

I posted over on Linguist's talk page, but it'd good to get a few eyes on this. Anyone else know Chinese? ···日本穣 · 投稿 · Talk to Nihonjoe 02:55, 3 December 2016 (UTC)

Proposal to create a rule changelog wiki page


Create a changelog of every change made to the ISFDB rules and standards. This changelog has nothing to do with the way a rule change is determined and the discussion which leads to a rule change. It only comes into play after that. I created an example how it could look like which contains one of the latest rule changes: User:Hitspacebar/Rules_and_standards_changelog

Why do we need this page?

Counter-question: if you go on holidays or a longer hiatus and come back here - how do you find out if, which and how the rules and standards have changed? Do you (want to) read all discussions on the rules and standards wiki page? That can be a lot to read. Also consider that older discussion are deleted from the wiki eventually.

Another reason: I had at least two situations where two moderators had a different "current practice" regarding submissions I had made. Therefore we definitely need a means which helps us to ensure that editors, moderators, documentation and current practice are as much as possible based on same current rules and standards.


It's possible that the changelog will be incomplete because nobody thinks about adding an entry after a rule change has been decided. See the following thread which could help to ensure a complete changelog.

See also

This thread is based on my initial proposal here and a subsequent discussion about it on Ahasuerus's talk page.

Jens Hitspacebar 20:37, 4 December 2016 (UTC)

A changelog will provide a quick overview of rule changes, which will hopefully help returning editors get up to speed quickly. Ahasuerus 23:57, 4 December 2016 (UTC)
Since there's no additional feedback I think we should start using this rule changelog. If there's no objection I'd move the page to its correct place at Rules_and_standards_changelog and add links to it here:
As for the separate template which I proposed in the thread below and which should help ensure that the rule changelog is always complete: I drop that proposal. Jens Hitspacebar 18:57, 7 December 2016 (UTC)

Create a standardized process for rule changes

I originally wanted to propose a new wiki template which should be added to each thread started on the Rules_and_standards_discussions page and which should help to keep track of the status of each discussion. It's goal is that with this template it's a lot easier to see if something has to be added to the rules changelog (see previous discussion thread) after a discussion is finished. Here is my proposal for this template: User:Hitspacebar/Template:RuleDiscussionStatus. This template can be seen as something similar to the status fields used in many ticket and bug tracking systems. They usually have a "status" ("open", "rejected", "resolved", "closed" etc.) and some also have a separate "solution" field ("done", "not relevant any more" etc.).

However, Hervé intervened and suggested that before we start using such a template we should discuss the way rule changes are decided - which is currently not a standardized process but more like an ad hoc process based on whoever coincidentally participates in a discussion.

In contrast to Hervés point I think that the template I'm proposing can be used regardless the way we decide about rules changes because this template is not a part of the discussion or the decision-making process. Whatever this process is or will be, the template is sitting on top of (or next to) it in order to keep track if there has been an outcome at all and help ensure that the rule changelog is updated (as long as we don't move these discussions to a completely different software, of course).

Maybe Hervé can chime in with his own words :)

So there are actually two things here:

  • If we want to implement the rule changelog I proposed in the previous thread: how do we ensure that each rule change is logged there? Is the template I am proposing for that sufficient, and if so, could we use this template without agreeing an a standardized rule change discussion result determination process before?
  • What should be the standardized process to determine the outcome of a discussion about rules and standards?

See also the former discussion about this on Ahasuerus's talk page.

Jens Hitspacebar 20:38, 4 December 2016 (UTC)

Thanks for the invitation, but I decline. Hauck 07:47, 5 December 2016 (UTC)
That comes as a surprise. You had a valid point regarding a missing standardized process for rule changes and thought you might have some ideas for an implementation. I hope there's nothing wrong (or even offensive) with my wording above which led you to your decision (if that's the case: that wasn't my intention). Hitspacebar 08:51, 5 December 2016 (UTC)
No, no, don't worry, there's nothing wrong with your intervention. I just don't want to enter a Nth debate without an outcome or worse, with an outcome based on an "ad hoc process" that is a complete mystery. Hauck 09:02, 5 December 2016 (UTC)

Entering Title notes at New Pub entry time?

Ahasuerus requested that I solicit the community's opinions about this. So please opine! :-)

Do people want/need the ability to supply title-level notes in the New Pub screen?

I recently noticed a number new pub submissions that placed what should have been Notes in the Synopsis field. The latter is made available on the New Pub screen, while the former is not. Some other recent edits moving information from Synopsis to Notes suggests a fair number of editors have done the same thing, and many times neither editor nor moderator has remembered/noticed to go move the information after the title record was created. I realize the sheer number of notes-like fields on New Pub is already daunting, but I'm wondering if empirical evidence isn't suggesting we ought to have provision for title notes entry there.

Ahasuerus pointed out FR 152 Add a new field for Title level Notes in the New Publication forms, but only display it when it's checked in User Preferences.

Considering the way that is worded, I suggest commenting on two aspects: (1) Should one be able to supply Title Notes in the New Pub screen and (2) Whether the resulting "notes" clutter matters and any thoughts about mitigating that clutter.

This isn't an R&S discussion, so we don't need to agree! All comments are grist for Ahasuerus' implementation mill. --MartyD 11:33, 9 December 2016 (UTC)

Yes, please! At least it would save editing the title entry just for adding the translator who belongs in there if there's one to credit. Stonecreek 12:11, 9 December 2016 (UTC)
I have been thinking about this issue for the last few days. I think the advantages of adding this field to the New Publication form, especially when dealing with translations, would outweigh the disadvantages, i.e. the extra clutter.
As far as the issue of making it a User Preference goes, I suspect that it would only add an unneeded layer of complexity. We can always add it later if requested. Ahasuerus 13:08, 9 December 2016 (UTC)
Heck yes, I say it's badly needed.
As for "some other recent edits moving information from Synopsis to Notes", that was me; I searched for mentions of editors or translators in Synopsis. No doubt there are other things needing moving that I didn't find that way. --Vasha 13:10, 9 December 2016 (UTC)
Just dropping in to say "Yes please". PeteYoung 14:25, 9 December 2016 (UTC)
Another "yes, please". I would also ask for the storylen to show up on the newPub (because of omnibi) but one battle at a time. Anniemod 17:15, 9 December 2016 (UTC)
"Yes!" from me. This would be very nice to have. I also like the idea of being able to add the storylen on new pub omnibuses (omnibi?). ···日本穣 · 投稿 · Talk to Nihonjoe 20:51, 9 December 2016 (UTC)
[OT: it is "omnibuses" because it is derived from the dative case form of the latin "omnis" (nominative case singular). The plural ending -i is only correct if the singular nominative case ending is -us.] --Vasha 21:48, 9 December 2016 (UTC)
Now, now, why inject logic in such a nice conversation :) I kinda know it is not omnibi but I like the word a lot so I am pretending that it is my bad English that makes me say it :) Anniemod 22:28, 9 December 2016 (UTC)
"Logic" has nothing to do with it when it comes to Latin. That's why I'm glad that English always allows us to form plurals by adding -es; we only do it the Latin way when we are trying to be fancy ;-). --Vasha 23:18, 9 December 2016 (UTC)
Unless it's "datum" or "bacterium" :-) Ahasuerus 23:37, 9 December 2016 (UTC)
Just to demonstrate that learning the Latin forms can't be done in five minutes, here are two quiz questions.
1. What is the Latin plural of "consensus"? Answer: "consensus". That's because it does not have the -us ending of words that form their plurals with -i; instead the ending is -ūs (with a long vowel), plural -ūs, but Latin spelling doesn't actually mark vowel length.
2. What is the Latin plural of "octopus"? Answer: "octopodes" (well... that isn't Latin, read on). This is actually a Greek word (ὀκτώπους) which, transcribed into the Latin alphabet using Latin spelling conventions, becomes "octopus". The Greek plural of that word is ὀκτώποδες (octopodes).
So... even though I know this stuff, you won't catch me showing off by using those forms... it's plain ol' "consensuses" and "octopuses" for me. --Vasha 23:18, 9 December 2016 (UTC)
I know enough Latin to get in trouble - had been planning to pick it up again and never seem to find the time or the will. Bulgarian has a lot of ways to form plural - there are basic rules based on gender but then there are so many exceptions that... And some words have double plurals depending on how you use it. When I started learning English, I was waiting for the other shoe to drop on the plurals and genders for a long time. Then I realized it just is that easy. Anniemod 23:24, 9 December 2016 (UTC)
Yes! It would save me a lot of additional edits. --Willem 21:09, 9 December 2016 (UTC)

(unindent) The motion passes by acclamation! :-)

The software has been modified and "Title Note" fields should be available in all New Publication forms. Re-checking things, I see that the field is missing the standard mouse-over Help, but that should be easy to fix. If you find any other problems, please report them here. The "story length" field will be added once the recently approved changes to its values are done. Ahasuerus 22:32, 9 December 2016 (UTC)

Can we please fix the help page here to mention the new field? Anniemod 22:45, 9 December 2016 (UTC)
Certainly. The "Title Note" template has been cleaned up and linked from Help:Screen:NewPub. The software has been updated to display a mouse-over bubble and link to the template. Ahasuerus 23:12, 9 December 2016 (UTC)
Awesome! ···日本穣 · 投稿 · Talk to Nihonjoe 23:44, 9 December 2016 (UTC)
Great, thanks! --Vasha 00:02, 10 December 2016 (UTC)
Having now tried it out... could you make the box maybe one line taller?
ETA: I just noticed the draggable corner to expand the box. That's handy! So never mind about the initial size. --Vasha 01:05, 10 December 2016 (UTC)
However, I think I use Notes a lot more often than Synopsis, so if that's true of everyone, the initial size of the two boxes should be reversed (Notes larger). --Vasha 01:09, 10 December 2016 (UTC)
Well, the original idea, which we discussed way back, was that synopsis data tends to be long-ish, hence the default size. However, it was mostly speculation based on our (then) limited experience. If the editors who actively use this field in 2016 need more space, it will be easy to accommodate their needs. Ahasuerus 01:22, 10 December 2016 (UTC)
My idea was that if people are using Notes 10 times more often than Synopsis, it ought to be the more visually prominent one so that no one accidentally puts their notes in the wrong box. As for needing more length, it's true that synopsises are long, but the draggability takes care of that. --Vasha 01:26, 10 December 2016 (UTC)
I'll be more than happy to change the default size if there is popular demand for it. Speak up, folks! Ahasuerus 22:24, 10 December 2016 (UTC)

(unindent) I post a note about a feature. I go to work. I come home from work. The feature's implemented and active. Magic! I could get used to this.... :-) --MartyD 01:58, 10 December 2016 (UTC)

Actually, it was merely sufficiently advanced technology. There would have been an extra charge for magic :-) Ahasuerus 22:24, 10 December 2016 (UTC)

NewPub/ClonePub/AddPub and transliterations - new user preference proposal

I would like to propose a user preference that allows an editor to see/add transliterations to the transliteratable elements while adding a publication. At the moment, if I am adding a novel in English or any other Latin-1 language, I need to make one submission. If I am adding one in Bulgarian, I need about 8 (the initial one, transliterations for the title, the publication, the publisher, the publication series, the cover art, the author, the artist for the cover). If I have introduction or any other essay inside or internal art, I need 1 or 2 per element(1 if we already have the author). For collections, we have 1 or 2 additional one per story... And that does not include varianting when needed, pseudonyming or any of those additional elements that you may have in English as well.

That's the same for any languages that use alphabets that have no Latin-1 characters (some of the Central European may be as bad but they have a chance to have some strings not needing transliterations :) I understand that most editors won't need to see these fields (thus the user preference) but anyone working in any of the non-Latin1 languages, that will be very helpful... I suspect that it may not be easy to implement but any improvements in adding those titles will be a good change. Thanks! Anniemod 02:25, 10 December 2016 (UTC)

Oh yeah, I guess it would be really nice to have the ability to do the transliterations at the same time as everything else when working in Turkish. At least for titles; names seem like less of an issue, since new names are added less often (and you then have to edit the profile in any case, to make sure that the working language, last name, etc. are correct). I think having the option (in preferences) to have a transliteration field below all titles wouldn't clutter things up too much. Oh, but Anniemod reminds me that I haven't been adding transliterations to publishers, pub series, and cover art titles! Yes, it would be nice not to have to go back and do all that. --Vasha 03:03, 10 December 2016 (UTC)
I've taken care of most of the ones you added lately :) They show up on a report, Turkish is easy enough for transliteration. You may want to check the cover art though - if it is not marked as Turkish, it does not show up on the report and I may have missed some. :) Anniemod 03:06, 10 December 2016 (UTC)
Thanks very much -- I noticed that some of them had been done, and didn't know it was you. --Vasha 03:33, 10 December 2016 (UTC)
I agree that it would simplify things considerably. However, as Annie correctly guessed, it would be a fairly significant change. More importantly, there are some design issues to consider. For example, at this time there is no easy way of telling if the publisher/publication series/author that you are about to enter already has a transliterated name on file.
At one point we discussed creating a second Web page which would be optionally displayed after you click "Submit". It would only appear if some of the entered values needed transliterations or if there were identical Contents titles on file which needed to be merged.
The approach seems to be desirable, but we'll have to consider all possible permutations. For example, what happens if one of the "to-be-merged" Contents titles is no longer in the database when the moderator reviews the submission? Will it make the submission "unapprovable"? That could cause a lot of painstakingly entered data to be lost, something that can't happen with NewPub submissions under the current system. Ahasuerus 03:34, 10 December 2016 (UTC)
An idea -- allow adding of transliterations where it makes sense on the forms. If there is already transliteration, allow the moderators to chose if they want to keep the old (the default) or replace with the new. Or just discard the new one and keep the old one in case it is there? A second page puts a lot on the order of submissions - what if I have mine waiting and someone else works on whatever I am merging into? This way, we won't lose work that is already done -- and if there is transliteration, it will stay in place.
So if the publisher is already in and I had checked that, I can leave the transliteration field -- and the one from the DB will be there. But if it is not there or I see it does not have a transliteration, I can as well take care of it with a new publication. I do understand that it is not trivial - but I am looking at a few thousand Bulgarian titles that a friend had agreed to work with me on (me entering, him verifying) and that will be a lot of waiting time and editing :)Anniemod 03:57, 10 December 2016 (UTC)

(unindent) Let's consider the use case that Annie mentioned earlier:

If I am adding one in Bulgarian, I need about 8 (the initial one, transliterations for the title, the publication, the publisher, the publication series, the cover art, the author, the artist for the cover)

The way New Publication pages currently work, "transliterations for the title, the publication" can be entered as part of the original submission, which leaves us with the following 5 fields:

  • Publisher
  • Publication series
  • Cover art
  • Author
  • Cover artist

Since we use the publication title as the cover art title, I think we should change the software to use the submitted transliterated value for the cover art title as well.

As far as the other 4 fields go, chances are that there will be more than one submission for each publisher, publication series, author and cover artist. All of them will be caught by the nightly cleanup reports and will require one submission per record to fix. If we were to add 4 new "transliterated value" fields to the NewPub form, editors would be prompted to enter the same information over and over again, which seems counterproductive.

That said, adding a "transliterated title" field to the Contents section may save time since Contents level titles are usually unique. It may be possible to add a button which, when clicked, would add "Transliterated Title" fields to the page. Ahasuerus 22:43, 10 December 2016 (UTC)

Last time I tried, a transliteration added to the title did not carry to the publication (I have a test in the queue if someone can approve it - in case my memory deceives me). Anniemod 22:59, 10 December 2016 (UTC)
I have approved the submission -- the results are here. (BTW, experience suggests that we need to be extra careful with test records since they have a nasty tendency to stick around much longer than expected.) Ahasuerus 23:08, 10 December 2016 (UTC)
It carried through so I was wrong on that reducing my old 8 to 6:) Still a lot of edits :) For the test record - I am aware so I have a note to delete it -- the pub deletion already submitted; title to follow, If I was planning to be away for awhile, I would have put my name in the title to make sure I can find it when I am back :) Anniemod 23:15, 10 December 2016 (UTC)
I have approved the submission and deleted the title record, so we should be in good shape now. Ahasuerus 23:23, 10 December 2016 (UTC)
Changing the software to pick up the transliterated cover art together with the work makes sense. And adding a button to add transliteration for content will make it manageable. Anniemod 22:59, 10 December 2016 (UTC)
OK, FR 958 has been created to take care of Cover Art titles. Ahasuerus 23:14, 10 December 2016 (UTC)
FR 958 has been implemented. Ahasuerus 17:24, 18 December 2016 (UTC)
I am reasonably sure that "Add Transliterated Title" should be doable, but we'll need to clean up the filing code first. At the moment it's so messy that adding more complexity may break it. Ahasuerus 23:14, 10 December 2016 (UTC)
FR 959 has been created. It's deliberately vague to allow multiple implementation paths. Ahasuerus 19:10, 11 December 2016 (UTC)

Transliterations for works with no language

I am not sure if one of the current reports need to be tweaked or we need a new one but I keep stumbling upon titles that need transliterations and which are nowhere to be seen on our reports - they are usually coverart, occasionally interior art records (I am not sure if there had ever been other types) and always without a set language. Can we get these on a report? I think that anything that contains a non Latin-1 character and has no transliteration should be on a report so someone can go, set the language(in the case when it is not set) and add a transliteration. This way we will know that all the old records are now cleared at least for that :) Anniemod 00:48, 11 December 2016 (UTC)

That's a good point. The cleanup reports that handle transliterated values are organized by language code. That way all Japanese titles are together, all Russian titles are together, etc. Then there is a "catch-all" report which handles less common languages. However, it ignores titles without a language code, an oversight. Bug 640 has been created. Thanks! Ahasuerus 01:02, 11 December 2016 (UTC)
The affected cleanup report has been updated to include titles without a language code. The data will become available tomorrow morning. We are looking at roughly 80 additional titles. Ahasuerus 17:32, 16 December 2016 (UTC)
Once everything in the queue is approved, these are all done. :) Anniemod 21:50, 17 December 2016 (UTC)

Add transliteration to "Make variant"

Can we have the transliteration field in the "Make variant" page (the lower part where you create a new title)? We already have the language and date here - if we can add the transliteration as well, we may not need an additional edit all the times when the original is in Russian/Bulgarian/Japanese and so on :) Thanks! Anniemod 22:26, 12 December 2016 (UTC)

Another good point -- FR 960 has been created. Ahasuerus 23:21, 12 December 2016 (UTC)
Done. Ahasuerus 01:08, 18 December 2016 (UTC)

New Cleanup reports proposal

I would like to propose 2 new cleanup reports:

  • Language mismatch in the same compound title - we do have billingual books and they can be ignored but we also have a lot of cases where the novel is set to French but the coverart either have no language or is set to English for example. This should pinpoint a huge ammount of the remaining non-English titles (short fiction, essays, arts records) - as soon as the main title language is set, these will be highlighted. That may even be an automated job - if no language is set, set the same as the container; if a language is set but is different, put on a report.
  • Container titles with no language (collection, omnibus, anthology, magazine, fanzine). A lot of those will be English but we will find a lot of non-English as well.

Thoughts? I am trying to find as many non-English titles as we can without needing to go through thousands of English titles. Anniemod 18:38, 16 December 2016 (UTC)

Let me start by re-posting something that I wrote on my Talk page a few days ago:
... the plan has always been to add languages to titles in two phases. During the first phase we were going to assign language codes to the "low hanging fruit" manually. During the second phase we were going to assign 'English' to the rest of the titles automatically.
The first phase has been a success in that only 46.3% of our titles do not have a language code assigned.
A few months ago I decided to check if we were ready for the second phase. I ran a few reports and found hundreds of authors like Philippe Druillet whose language-less titles are a mix of English and French records. Clearly we weren't quite ready for "phase 2".
I think the next step is to use this cleanup report, which finds author/language mismatches, as a template and build on it. What we need is a cleanup report to find language-less titles by non-English authors. There are 18,290 of them, which may seem like a lot, but it's just 3% of the total number of language-less titles. Once they have been upgraded, we can move on to "phase 2". And there will be much rejoicing! :-) Ahasuerus 04:26, 15 December 2016 (UTC)
FR 961 has been created. Ahasuerus 04:41, 15 December 2016 (UTC)
A further review revealed that we already had a cleanup report which showed "language-less titles by non-English authors". However, it was limited to non-art titles. I didn't want to add art titles to the same report because it would have made it difficult to find non-art titles. Instead I created a new cleanup report and deployed it earlier today. The data will become available tomorrow morning.
I also like Annie's idea re: automating some parts of the language assignment process. If a language-less art (COVERART/INTERIORART) title is associated with a publication whose "reference title" has a language code, I think it should be safe to assign that code to the art title automatically. I'll need to run a few checks to see if I am missing any potential issues. Ahasuerus 22:33, 16 December 2016 (UTC)
How about short fiction and essays in that second case (and even interviews, reviews, poems and other internal elements)? Any reason they cannot automatically get the language code as well? The only problem will be bilingual editions and these won't have a language set on their reference title (or if they do, most likely their content will also be set). That will eliminate a huge amount of now language-less titles allowing only true unknowns to remain behind... Anniemod 23:11, 16 December 2016 (UTC)
If the guinea pigs do well, the rest of the menagerie will be next :-) Ahasuerus 23:19, 16 December 2016 (UTC)
One more thing - magazines and fanzines. I was looking at Amazing Stories and none of the editors from before 1993 that I checked have the language set. Fanzines and magazines do not change their language during their runs. Any way to be able to mark a fanzine/magazine language so that some kind of automation can set the editors (and then the inside titles if the plan work out)? Anniemod
I assume the algorithm would look something like:
  • Examine the EDITOR titles for each series
  • If none of them have a language code assigned or if there are 2+ language codes, skip the series
  • Otherwise retrieve the language code and assign it to all language-less EDITOR titles in the series
I can't think of a scenario where the algorithm would fail. Ahasuerus 22:57, 17 December 2016 (UTC)
Sounds good. Then it will come down to assigning language to 1 EDITOR only (if the series has none - which may be true for some of the older series that had not been worked on lately) and that is manageable. Maybe throw on a report the ones for which language cannot be determined(so someone can go and set 1 record properly) and the ones where there are different languages assigned (so someone can see if that means two magazines that need to be split or a wrong language assigned or something like that? The only thing I would be worried if a magazine with no language has one editor wrongly set to English and that gets populated everywhere but... short of checking all magazines, I do not see how we can prevent it - and we do need some automation. Although if the editor has their language set correctly, that would show on the language mismatch report (it includes EDITOR, correct?) so it should be caught before all of them are set. Annie 23:07, 17 December 2016 (UTC)

(unindent) So, should I work on those 500 art pieces that need language now in the new report or should I give you a few days to see if we will be able to set it automatically (most of them are attached to publications that already have a language)? Anniemod 20:59, 17 December 2016 (UTC)

Well, the new report was written before I saw you proposal re: automatic language assignment. My current thinking is that there is no harm in cleaning up a few dozen titles manually. Perhaps we'll see additional patterns that may help us come up with a better auto-assignment algorithm. Ahasuerus 22:31, 17 December 2016 (UTC)
Or a few hundred - if I start on them :) They are perfect for what I need right now - not too much thinking, no external verifications. I will count how many would have not be caught by an automated "assign the reference title language" script to see how it looks like. By the way, all of the no-language transliterations would have been assigned languages properly this way (just as a reference point) - they would have still needed transliterations but languages would have been there. Anniemod 22:43, 17 December 2016 (UTC)
Now that the majority of language-less titles have been handled automatically, the number of outstanding art titles has dropped to 551. Consequently, the latest and greatest version of this cleanup report is no longer limited to 500 titles per day. Ahasuerus 23:12, 20 December 2016 (UTC)

Import Content and Make Variant changes

The layout of the data entry forms "Import Content" and "Make Variant" has been changed as per FR 955. The goal was to make it clear that each form supports two different options/paths. There was no other change in functionality. Ahasuerus 00:17, 18 December 2016 (UTC)

I like it. --Vasha 23:27, 18 December 2016 (UTC)

Availability update - 2016-12-17

There are some pesky "real life" issues which may affect my availability in the near future. In the unlikely event that I suddenly become unresponsive and stop updating ISFDB Downloads, please contact Al von Ruff who has full access to the server. I have created ISFDB:How To Create a Public Backup File to help ensure backup continuity. Ahasuerus 01:59, 18 December 2016 (UTC)

Best wishes to you as you try to deal with this. My thoughts and prayers are with you. Chavey 06:51, 18 December 2016 (UTC)
Thanks! Ahasuerus 13:50, 18 December 2016 (UTC)

Multilingual publications

A new cleanup report, "Multilingual Publications", has been deployed. The data will become available tomorrow morning.

The report looks for publications which contain titles in multiple languages, e.g. French and Spanish. A number of them are legitimately multilingual (and moderators have the ability to ignore) but the majority are not and will need to be fixed. For example, a few dozen Italian magazines are still using the old, pre-2011 data entry standard for translations. Ahasuerus 23:10, 18 December 2016 (UTC)

Awesome. A lot of those have their coverart set to the wrong language (default most likely for the entering).:) Is that catching a "no-language, English" pairing or is it only for proper language codes? Annie 18:12, 19 December 2016 (UTC)
It's the latter. Language-less titles are next on the chopping block... er, list. Ahasuerus 18:50, 19 December 2016 (UTC)
Makes sense. Let me go and take a look at one of the ones I was working on then - it looked as if there was one missing language only but because it was the anthology itself, none of the stories were showing languages - I suspect that once approved, I will see which one complains without the need to open each story to verify. Annie 19:21, 19 December 2016 (UTC)
How is cover art going to have a language? If a book gets published somewhere around the globe and a picture of e.g. Dutchman Hieronymus Bosch (died 1516) is used, does the picture suddenly have a language other than that of the painter when he made his piece of art?--Dirk P Broer 01:03, 20 December 2016 (UTC)
It shows in what languages the art had been used - the art does not change but the usage is different (and its title may be different -- otherwise you will end up with a Latin letters name on a Bulgarian book when that same one is used on a Bulgarian book. Or a Japanese lettered one on an English one and so on... Annie 01:17, 20 December 2016 (UTC)
So the language of the art can be defaulted into the language of the publication record it is used in?--Dirk P Broer 02:08, 20 December 2016 (UTC)
Yes, that's how the software works now. When you create a NewPub submission, you specify a language. That language is assigned to every title in the new publication, including its COVERART title(s). Ahasuerus 02:17, 20 December 2016 (UTC)
We once had the idea to disassociate most of the art from languages (apart from maps, comics and cartoons). I do think that it's still worthwile. In principle, Dirk is right: art in general has no language, only it's title has (whereas fiction has a defining language). We could spend our time with other things than determining the language of a piece of art (which has none). Stonecreek 05:21, 20 December 2016 (UTC)
So there is Interior Art called "Some Book [2]" in a book. I get the book and I identify it as the painting "Момиче със слънчогледи" of some Bulgarian artist. Do you propose that we use the original art name and set the language to Bulgarian (or leave it language-less if language is removed) but using the original name in the original language instead of varianting into the original record instead? Cover Art is different - as it follows the title for the most part (although why would we treat the two differently?)Annie 19:21, 20 December 2016 (UTC)
I find that having a COVERART title's language displayed can be handy. For example, let's consider this COVERART title by Josh Kirby. It has 4 COVERART VTs and 2 INTERIORART VTs. Of the 6 VTs, 2 are associated with English books, 2 with German books, 1 with a French book and 1 with a Dutch book. The ability to see each VT's language on Title and Bibliography pages is very nice and I wouldn't want to lose it. Ahasuerus 20:14, 20 December 2016 (UTC)
I am trying to make the same argument for INTERIORART as well - being able to see what languages the art is used in is something that I will hate to lose. Annie 20:21, 20 December 2016 (UTC)
Personally, I'd think it'd be enough to display the variant titles (after all, we are at work to catalogue fiction, art somehow was an addition). I think most of us are able to have an idea about the language of the book the piece was published in. So, are there more opinions on that topic? Stonecreek 04:54, 21 December 2016 (UTC)
Also, it's really meaningless to assign a language to a painting by, say, Karel Thole or Salavador Dali (if they spoke one language in their works it's the one of surrealism). Thole's work was reproduced widely in many publications from different countries. For him and most other artists we'd have such a vast amount of work of differentiating to do. If a cover for an issue of Urania is reproduced in a German publication (and there are quite a lot of, and they are titled as such), we'd have to set the language for that publication to Italian, others to Dutch, some also in English, still others would remain German). And all that while the art itself has no language, only the editor or the publisher decided to give a title to it. Stonecreek 05:07, 21 December 2016 (UTC)

ISFDB Downtime - 2016-12-20

The ISFDB server will be unavailable between 5pm and 5:20pm server (North American Eastern Standard) time. There is a chance that the downtime may last a bit longer than estimated. Ahasuerus 21:41, 20 December 2016 (UTC)

The server is back up. The language auto-assignment process has been run and we are down to 112,171 (8.96%) language-less titles. Ahasuerus 22:16, 20 December 2016 (UTC)
Plus the 238 undefined :) Annie 22:20, 20 December 2016 (UTC)
Indeed. I am not sure how they reproduce, but I suspect that it has to do with title merges and/or unmerges. I hope that they will disappear once we complete the language assignment process. Ahasuerus 22:31, 20 December 2016 (UTC)
And here is one small side-effect: Russian Publications with Latin characters - probably because of some of the art pieces being the only language-assigned items - I will clean these now but outside of that the auto-assignment seems to have run pretty well. Annie 16:25, 21 December 2016 (UTC)
Clarification because the example won't be there for very long. The language in The Baum Bugle - 1980 got set to Russian because of the Russian illustrations in one of the magazines under it being the only title with language. Which caused it to change it on all 3 publications and its titles. Nothing else bled into the non-Latin languages - it may be possible that some Latin cross-assigning happened where there was a single wrong title with a languages. Annie 16:57, 21 December 2016 (UTC)
Yes, that's exactly right. If we end up with 100 invalid language auto-assignments out of 433,000, we'll be in pretty good shape :) Ahasuerus 17:35, 21 December 2016 (UTC)
I do not disagree - I just saw it and thought I should mention it :) Annie 17:47, 21 December 2016 (UTC)

EDITOR with no language report proposal

Based on what we had been discussing about EDITOR records not having languages (and a lot of language-less titles being parts of them), can we get a report of all EDITOR titles with no language so the non-English ones can be picked out, leaving only English ones (and then language can be set automatically for them enabling then cascading the language)? Same for Collections and Anthologies I would think if the numbers are not too great... Annie 23:22, 20 December 2016 (UTC)

Here is where we stand at the moment:
| title_ttype  | count(*) |
| INTERVIEW    |      288 |
| SERIAL       |      393 |
| OMNIBUS      |      448 |
| EDITOR       |      788 |
| ANTHOLOGY    |     1067 |
| POEM         |     1467 |
| CHAPBOOK     |     1490 |
| COLLECTION   |     1845 |
| REVIEW       |     3296 |
| NONFICTION   |     4449 |
| ESSAY        |     9872 |
| INTERIORART  |    10453 |
| SHORTFICTION |    17046 |
| COVERART     |    22374 |
| NOVEL        |    37300 |
The plan is to create a cleanup report which will identify language-less "container" titles of the following types: OMNIBUS, EDITOR, ANTHOLOGY, COLLECTION. We will probably do it one title type at a time to make the report more manageable. Once these container titles have been cleaned up, we will re-run the "automatic language assignment" script and re-evaluate where we are. Ahasuerus 00:39, 21 December 2016 (UTC)
How about adding CHAPBOOK as well so we can clear those as well? Maybe after Collection and EDITOR and after the automation is run based on that? Annie 00:58, 21 December 2016 (UTC)
Chapbooks are typically reprints, so I am not sure how much we will gain. Once the 4 big ones have been taken care of -- BTW, it occurs to me that we should run the auto-assignment script after each one -- we can review what's left and determine the best course of action. Ahasuerus 01:19, 21 December 2016 (UTC)
Version 1 (OMNIBUSes) of the report has been coded and deployed. The data will become available tomorrow morning. Ahasuerus 01:24, 21 December 2016 (UTC)
Yes, that's why I said after the first 4 - a lot of their stuff will be caught before that but there may be some remaining (especially short European novels that are not novels really:) ). And running the script after each is probably a good idea - this should eliminate more titles eventually... Annie 01:28, 21 December 2016 (UTC)
With any luck, the auto-assignment script will make everything (but NOVELs) much more manageable. NOVELs... well, there may be ways to identify non-English novels and then assign "English" to the rest. Ahasuerus 01:34, 21 December 2016 (UTC)
And Non-fiction... The cleanest way I can see for those 2 categories may be to start reviewing short-ish lists of them (alphabetically or whatever), assign non-English, skip the English and clearing them for assignment of English to the whole group... Annie 01:55, 21 December 2016 (UTC)
Well, the brute force method is our last resort, but there may be other things we could do first. For example, we may be able to auto-assign English to titles associated with pubs published by established US/UK publishers. Ahasuerus 17:38, 21 December 2016 (UTC)
That sounds like a better idea :) Or even identify the publishers that have more than X non-language NOVEL/NON_FICTION and figure out the language for them . In case the assignment based on the known names leaves too many that is... Annie 17:49, 21 December 2016 (UTC)

Writers of the Future and Illustrators of the Future as awards

Okay, trying this again since the last discussion never really decided anything. (^_^)

For the Writers of the Future, there should be the following awards:

  • "Golden Pen" (annual, picked from the quarterly winners, should have a note indicating it's been called the "Grand Prize" at various times, too)
  • "Quarterly First Place"
  • "Quarterly Second Place"
  • "Quarterly Third Place"
  • "Quarterly Finalist"

For the Illustrators of the Future, there should be the following awards:

  • Golden Brush" (annual, should have a note that it's been called the "Grand Prize" as various times)
  • Finalist

If there are some that are slightly inconsistent, we can make a note on them. ···日本穣 · 投稿 · Talk to Nihonjoe 19:09, 21 December 2016 (UTC)

Availability update - 2016-12-21

My computer time will be very limited for the next week or so. I should be able to handle the weekly backups, but otherwise development and Fixer will be on hold. Ahasuerus 20:38, 21 December 2016 (UTC)

Hopefully not for a bad reason. Have a good holiday week. Annie 22:50, 21 December 2016 (UTC)
Have a good break --Vasha 09:36, 22 December 2016 (UTC)

Dating of Granta

Here'a a slightly complicated one. Granta (which sometimes publishes genre stories) has two versions with completely separate tables of contents, one print/ebook and one online. Both of them have the same issue number. The print version (example preview) is dated according to season (Autumn 2015). The online one also has its TOC listed on a page with that date. However, the stories are posted online gradually over time, with each one having a posting date on its own page. Example: "Click" states that it's published in "Granta 133: What Have We Done | The Online Edition / Fiction / 14th January 2016". So, which date to use? Is "Click" a 2015 story (according to the issue date) or a 2016 one (according to the date on its page)? --Vasha 09:55, 22 December 2016 (UTC)

Personally, I'd use the earlier date (2015) and would consider the posting as a reprint with its own later date. Hauck 10:05, 22 December 2016 (UTC)
Reprint? But it wasn't in the print edition, the web is the first appearance. --Vasha 10:11, 22 December 2016 (UTC)
In this case, the two editions (print and online) should be separated (like we do for Clarkesworld, IIRC) and the story be present (with a 2016 date) only in the "electronic" issue. Hauck 10:34, 22 December 2016 (UTC)
Even though the table of contents of the online edition also had the date Autumn 2015? Are there other examples where stories have a date attached to them which is not the date of the issue they are in? --Vasha 10:42, 22 December 2016 (UTC)
Well, than the example story is to be dated as a 2016 publication with an accompanying note why the magazine's dating is misleading. Stonecreek 13:55, 22 December 2016 (UTC)

(unindent) I think I have made up my mind. It's the usual practice to give magazines the cover date instead of the date they actually were placed on the newsstands, right? I am going to say that the "date" on the story pages is the latter, they are in the Autumn 2015 issue and "went on sale" another date -- so then they should be in the DB as Autumn 2015. Does anyone disagree with that? --Vasha 19:04, 22 December 2016 (UTC)

I would look at awards eligibility for proper dating I think. A story in Analog January 2016 for example is eligible for 2016 even if it is published in November 2015. This online story is dated on its own and as such is eligible for 2016 according to how I read the rules for eligibility - so it should be a 2016 story here I think... - with a note in the publication on why some stories are not as old as the issue (as Stonecreek proposed above). Annie 21:14, 22 December 2016 (UTC)
If the web-only version doesn't have a downloadable version (PDF, ebook, etc.), then it shouldn't generally be included here per ISFDB:Policy#Excluded. ···日本穣 · 投稿 · Talk to Nihonjoe 22:18, 22 December 2016 (UTC)
The story will make it into the DB sooner or later as it is from a print collection anyway. :) But I think I will start a separate discussion on what "downloadable" means these days - "Strange Horizons" do not have a downloadable form either for example and it is definitely in scope here. Plus there are plugins that create ebooks from a story (and send it to your Kindle automatically these days). So we do need to precise that language a bit... Annie 22:34, 22 December 2016 (UTC)
Good point on awards, Annie-- but couldn't some eligibility rules disagree with each other? To choose only the award most relevant to this particular story, the Stoker Awards say this: "In the case of works first appearing in magazines or other periodicals, the date of publication which appears on the magazine, commonly referred to as the 'cover date' -- rather than the date of distribution -- will determine eligibility. If there is no cover date the date of first release will apply." I argue that the online edition of Granta 133 DOES have a cover date-- it's on the page with the Table of Contents. By Stoker rules, that takes precedence over all other dates.
@Joe-- the story was published in a collection later in 2016, so I should determine the date of first appearance to put in the title record, even if the online publication isn't catalogued. --Vasha 22:39, 22 December 2016 (UTC)
I am not sure that it does actually - the rule is written with printed magazines in mind and I have a suspicion that this story will get its eligibility from the 2016 date on the story itself (as it is not part of the printed magazine that came out earlier). I guess sooner or later someone somewhere will need to make a determination on these cases (because if you look at the Riles forum, I have a similar question for another journal and an online-only story there (thankfully with a clear year) :) The new world of publishing is a headache-inducing mess... Annie 22:47, 22 December 2016 (UTC)

Cleanup for Imprints of Publisher Grimbold

I am not sure what the best way to handle this would be. Would an experienced editor be willing to do this cleanup as appropriate?

These two should be merged:

website: Kristell Ink | The Sci Fi and Fantasy imprint of Grimbold Books

This one should be corrected:

website: Tenebris Books | Dark Fiction imprint of Grimbold Books

Thanks much. JJ 23:28, 22 December 2016 (UTC)

Story Lengths for The Starlit Wood

ISFDB: The Starlit Wood: New Fairy Tales

In response to a query from me, I received the following message from Saga Press: "No novellas, but the following titles are novelettes (7,500 words - 17,500 words):"

  • Pearl by Aliette de Bodard
  • The Briar and the Rose by Marjorie Liu
  • Spinning Silver by Naomi Novik
  • The Other Thea by Theodora Goss

The rest are short stories. If an experienced editor is willing to make that change, I'd much appreciate it, and then I'll mark the whole entry "Verified". Thanks much! JJ 23:35, 22 December 2016 (UTC)

I've submitted the change. As soon as a moderator approves it (which may take a bit of time), all of the stories in the book will have their proper length specified. Annie 23:49, 22 December 2016 (UTC)
And now approved. Annie 03:15, 23 December 2016 (UTC)

Bulfinch's Mythology

I have been looking at the last two volumes of Bulfinch's Mythology and it seems to me that they are Nonfiction rather than Collection -- that is, the recounting of legends is done as chapters, not all of which stand on their own. I plan to change them if no one disagrees. Also, does anyone have a copy of the first volume, The Age of Fables a.k.a. Stories of Gods and Heroes, and can say if it's organized the same way? --Vasha 17:08, 24 December 2016 (UTC)

I have a copy of the 1978 Avenel Books omnibus. It has these major sections and organizations:
  • First sections, having chapters:
    • "Stories of Gods and Heroes" -- Chapter I (Introduction) - Chapter XLI (The Druids -- Iona)
    • "King Arthur and His Knights" -- Chapter I (Introduction) - Chapter XXIII (Morte d'Arthur)
    • "The Mabinogeon" -- Introductory Note + Chapter I (The Britons) - Chapter XIII (Taliesin)
  • Subsequent sections, not having chapters:
    • "Hero Myths of the British Race -- Beowulf - Robin Hood
    • "Legends of Charlemagne" -- Introduction - Ogier, the Dane (continued)
Despite the "Chapter" designations, each piece is a story in itself. And it looks like the final volume did not use chapters. --MartyD 12:15, 25 December 2016 (UTC)
Fair enough! Would you be willing to enter the contents for these collections, then? --Vasha 20:06, 25 December 2016 (UTC)

Working language question

Our help page description of "working language" says, in part, "For bilingual authors enter the more frequently used language." Even though Eduardo Barreto's first language is Spanish, every one of 6 credits is listed as being in English. Those are all illustrations, so "language" may be more-or-less irrelevant, but still it seems that his "working language", by our definition, is English. And that we should have a Cleanup Report that finds authors like this. Chavey 03:36, 26 December 2016 (UTC)

But we do not have all his credits in the DB - the DB is still mostly English. So if we use only what we have here, a lot of authors will end up English when they never really worked in English. And we do not always have the translation credit especially in older content. Illustrators are obviously more complicated but I would say that if they lived in a non-English country and were born there, the language follows them. Annie 06:16, 26 December 2016 (UTC)
I agree with Annie. If we can determine what their actual language is (especially if their work is only known through reprint or translation), we should set their language to that. Perhaps this needs to be moved over to Rules and standards discussions so it can be properly discussed in the right venue? ···日本穣 · 投稿 · Talk to Nihonjoe 18:04, 26 December 2016 (UTC)

(unindent) It sounds like there are at least three separate questions here:

  1. Should we have a new cleanup report to identify authors whose "working language" is not the same as the language of the majority/plurality of their canonical titles? (My take on it is that it would be useful.)
  2. If implemented, should this cleanup report allow moderators to "ignore" authors? (My take on it is that the report should support the "ignore" capability. The fact that our coverage is of necessity partial is a sufficient reason.)
  3. What should we do about artists whose art has appeared in multiple languages? (My tentative take on it is that the "most frequently used" rule still applies, but we have to be careful because it's harder to identify the original language of artwork.)

Ahasuerus 16:43, 27 December 2016 (UTC)

As stated before: While it may be useful to have a working language for artists, I don't think it's useful to have individual artworks assigned a language. Multi language artists like Karel Thole (born in the Netherlands, having lived most of his life in Italy, original artwork published with Dutch, Italian, English and German publications, multiple reproductions at least in Italy & Germany, with varying language titles, but it's always the same piece of art). We really could reduce the amount of time for handling 'languages' of art pieces, where they only get a title attached. Stonecreek 16:53, 27 December 2016 (UTC)
Well, the number of "language-less" titles is now down to 8.9% of the total number of titles. At the rate we are going, we'll hit 0% some time in early 2017. Once that happens, there will be no way to create new "language-less" titles, so the problem will go away. Ahasuerus 18:08, 27 December 2016 (UTC)
With a lot of art, the language is "irrelevant", but there are occasional pieces of art that have text within them, where the language is relevant. So I don't think I would want to remove language from art, but it may be useful to have a "language" option that is "irrelevant" (or some synonym of that). Chavey 22:56, 27 December 2016 (UTC)
Even if it is irrelevant, it makes it possible to find easy enough how many Thule illustrations had been used as covers in Bulgarian books for example. If we mark those as irrelevant, that will require inspecting all his works to see if a Bulgarian book is somewhere in the list. I know we are not Art Central but if we have the information, we may as well make it searchable easily enough. And while a German title on a painting is fine in another Latin language, it will be confusing on a non-Latin one or when the cover or interior art of an English book ends up with something with Russian letters or Japanese letters. Annie 23:47, 27 December 2016 (UTC)
The pieces where language is relevant were reduced to cartoons and maps in a discussion ca. two or years ago. But even for those the difference would be reflected in the titles. We seldomly would record more than the title for them (but if somebody wishes to add the details, such as countries or places for maps: as before, it'd be possible to do so in the notes).
What it does lead to is highly irrelevant and futile questions: 1) What language would a reproduction of Kepler's Somnium, seu Opus posthumum de astronomia lunari, divulgatum a M. Ludovico Kepplero, .. have assigned in a Bulgarian publication? 2) Which language should be assigned to Barclay Shaw's cover for Neuromancer, as it was published on English and German publications?
I'd also think that the question of usage for an artist like Thole could only be solved meaningful computationally, and it shouldn't be a concern for a database devoted to fiction. It's also still quite simple not correct to assign a language to a piece of art. Stonecreek 15:56, 29 December 2016 (UTC)
I don't want to enter a philosophical debate about art and language (just as an aside we're not talking here about pieces of art but about book covers or interior illustrations). For the record, I'm very attached to the concept of language for COVERART or INTERIORART (for the same reasons cited by Annie) and would be very unhappy to see all this work and all this painstakingly entered data written off. Such pages are extremely valuable to study the visual marketing of SF and the diffusion of SF stock images. Hauck 17:39, 29 December 2016 (UTC)
Sorry, Hervé, but philosophical questions about the language of a piece of art is exactly what one will get when we stick to the idea that language has to be added to cover art and interior art. It's absolutely not philosophical to see that a piece of fiction is made out of language, and a piece of art is not! And as we have artists like Pablo Picasso, Salvador Dali and Edvard Munch (to name a few prominent ones) in the database we are not only talking about cover & interior art but about the original pieces of fine art as well. (Aside: the cover art of Tim White, as an example, has been published in Germany on covers as well as interior art; the latter using the original English titles as well as made-up German ones; Thole's art was published similarly).
Has Munch's The Scream really the language English? What language has the original? Should it be Norwegian (as Munch was of this nationality), French (as it seems to be painted in & the first exhibition seems to have been in France), or German (as Der Schrei der Natur was the initial title chosen by Munch)?
Also, one should think that a short glimpse on the list of variant titles suffices to get an idea on the languages of publications the piece was published in (which could be in turn in a variety of languages: original, adapted, untitled etc.). As the scope of the database is growing in pieces as well as in languages we really will run into multiple heated debates on the language of art pieces that we could easily avoid (because it's futile and none of our business). Stonecreek 05:48, 30 December 2016 (UTC)
(outdent) I think we have to agree (and update documentation appropriately) on what the language field means. If we agree that for artwork, the language field merely represents the language of the publication the artwork appears in, then this concept is manageable. If it is an attempt to assign language to the art itself separate from the publication, then this becomes the unmanageable mess Stonecreek describes. I always envisioned the first definition and so have been okay with the field. If the latter, then I would object as well. It's clear we don't have agreement on that yet. Not just Stonecreek's comments, but also Chavey's "there are occasional pieces of art that have text within them, where the language is relevant" comment above. If a cartoon in an English language magazine happens to use a foreign phrase, it would still be English by the first definition. As for Ahasuerus's question three above, for artists I would recommend the working language be the artist's "native" language and not the language of the publications they most often appear in within ISFDB. Caspar David Friedrich was 19th-century German Romantic landscape painter, but publications in the database using his work are, except for one French, English. -- JLaTondre (talk) 14:22, 30 December 2016 (UTC)
I'm afraid that the first version won't work: See pp. 34-36 of this publication (Staatenschiffe der Tarnii KOLTOROC, artwork & shortfiction): if this would be reprinted in an English publication (for example in a nonfiction work on the Perry Rhodan series) the artwork would be English but the accompanying shortfiction German (both pieces bearing the same title proper). We would deal with artwork completely contrary than with texts.
If we stick to that idea we really are down the road of endless discussions on the language of specific artworks AND WE REALLY HAVE TO DO MORE MEANINGFUL THINGS WITH THE FICTION PART OF THE DATABASE.
The idea of sticking a language to an artwork may look nice but it does make things very complicated. Stonecreek 06:31, 31 December 2016 (UTC)
Yes, it does work. The vast majority of publications are single language. A English language publication is most likely going to use a translation of the German shortfiction; not the original German so there is no disconnect. For the few (relatively speaking) multi-language publications, a simple corollary to the original definition solves any issues: if the artwork record is for the publication as a whole (cover art, a single record entered for all artwork, fep, etc.), use the publication language. If the artwork is for a specific content in the publication, use the language of the that content. While I'm sure a more convoluted hypothetical can be imagined, I'd wager it would actually be an issue with our ability to only assign a single language to a text, not specific to artwork in general. -- JLaTondre (talk) 13:43, 31 December 2016 (UTC)
I suspect that your proposal with work in 99.9% of all cases. The only time a question may arise is when dealing with art books and other publications which reprint covers/interior art. For example, The Baum Bugle has reprinted Russian and Japanese illustrations from Oz and Oz-related books. They even kept the original captions in some cases. Should a Russian/Japanese/etc cover reprinted in an English/Polish/etc book keep the language of the original book or should it be assigned the language of the publication? Ahasuerus 20:47, 31 December 2016 (UTC)
I concur, "If we agree that for artwork, the language field merely represents the language of the publication the artwork appears in" is exactly (and no more) what I'm defending. I'm only interested to know that an illustration is used by such and such publication and in what language are these publications, the whole data being avaliable at a glance (that is without having to go to each publication title -that's two clicks away at best-). In fact, I'm just simply not interested to know in what language "are" Foss' paintings, just the language of the books they appear on. Hauck 14:59, 31 December 2016 (UTC)
Still, it would suffice in 99.9 % of the cases to look on the titles displayed to grasp what language it is. There are oh so few cases ("Solaris" or "Neuromancer") where you have to dig a little deeper.
There are ever more artists who aren't bound to one national market, and tend to title their works in English (like Volkan Baga). Their works would be assigned French in a French publication, German in a German publication & English in an English language publication and varianted. Quite often it'd come out that not the English publication (say, in the Spectrum series) was the first, but one in another language: you'd have to revise all the varianting, instead of just merging the identical titles which would represent identical artworks. That'd be quite absurd!
To say it again: texts are made out of language, art is not! We'll run into trouble assigning language to art - we already have (absurd for we aren't an art database).Stonecreek 15:47, 5 January 2017 (UTC)

Availability update - 2016-12-27

Sorry about the somewhat cryptic "availability updates" earlier, but I didn't want to be too specific until I knew the prognosis.

Basically I ran into some unexpected health issues a couple of weeks ago. It looks like things should be back to normal in the near future although my productivity may be on the low side for a while. I don't expect a permanent change in cognitive abilities at this point. Well, aside from the fact that, as John W. Campbell, Jr. once pointed out, no one is getting any younger :) Ahasuerus 23:33, 27 December 2016 (UTC)

Take care of your health - anything else can wait. Wish you a speedy recovery (or improvement if full recovery is not in the cards). Annie 23:43, 27 December 2016 (UTC)
I hear you. Take your time and get better soon. (that almost sounds contradictory) ···日本穣 · 投稿 · Talk to Nihonjoe 23:55, 27 December 2016 (UTC)
That's too bad -- best wishes. --Vasha 01:21, 28 December 2016 (UTC)
Thanks for the kind words! There has been no discernible permanent damage, so full recovery is likely. Looking forward to more patches in 2017! :-) Ahasuerus 17:32, 28 December 2016 (UTC)
While aching with a minor illness I hadn't covered the wiki (& the db) for the last days. I wish you the very best for 2017 (and the rest of 2016!). Christian Stonecreek 17:37, 29 December 2016 (UTC)
Glad to hear that things appear to be developing in the right direction (uphill). Keep on that road! (I say, writing from the emergency room where they seem to be getting my wife on that road as well.) Chavey 17:06, 30 December 2016 (UTC)
Thanks! Hopefully things will work out for the best for all of us in 2017! Ahasuerus 17:55, 30 December 2016 (UTC)

Non-genre Shirley Jackson

Would it be all right to delete Shirley Jackson's non-genre stories? True, her supernatural fiction is very important, but it's only a small part of her work. Her summary page would have three times as much below the line as above if I simply marked things "non-genre". --Vasha 04:36, 29 December 2016 (UTC)

OK for me. Hauck 08:21, 29 December 2016 (UTC)
By the way, "After You, My Dear Alphonse" and "The Renegade" are in The Supernatural Index but this surely must be a mistake; you can read extensive summaries of them respectively here and here. Do Ashley & Contento ever make mistakes like that? --Vasha 19:06, 29 December 2016 (UTC)
Well, no bibliography is perfect, as Robert Reginald, an occasional ISFDB editor, used to say. I have been exchanging e-mail corrections with Bill Contento and Dave Langford (the SFE3 maintainer) for years. Ahasuerus 19:35, 29 December 2016 (UTC)
I'm inclined to think of her as well "above the threshold". (When L.W. Currey is selling three of her genre books for ≥ $1,000, that kind of demonstrates her importance.) One of the things about the non-genre listings is that it tells genre collectors of an author which books to *not* bother getting, and for the important authors, that's really useful information. Chavey 17:12, 30 December 2016 (UTC)
I was also thinking that it would be kind of nice to have the non-genre work listed for reasons similar to what Darrah said -- so people could look at a story and see definitely that it was non-genre, rather than wondering if we just hadn't listed it yet. The problem is that if you apply that logic to all authors who have a lot of non-genre work, you start listing everything ever. The whole concept of a threshold was to prevent that. Is one of the nebulous criteria for this line that the author is important? Even if they‘re not about 50% genre? I have made a rough survey of Shirley Jackson's fiction, and came up with about 42 short stories and 4 novels in the genre, about 120 stories and 2 novels out of it. That's 35% or so. --Vasha 19:04, 30 December 2016 (UTC)
Someone correct me if I'm wrong, but I believe for non-genre works of "above the threshold" authors, we do include book-length works (i.e., non-fiction books, novels, collections, and, I suppose, possibly chapbooks), but not short works contained in other publications. --MartyD 11:30, 5 January 2017 (UTC)
I agree. Hauck 09:05, 6 January 2017 (UTC)
To quote the Rules of Acquisition, "This includes any non-genre works published as standalone books as well as non-genre short fiction...". The policy specifically allows non-genre short fiction. I think it comes down to what do you mean by "other publications". If you mean a non-genre magazine or a non-genre anthology, then I would agree as those publications don't belong. However, if it's collection of an above-the-threshold genre author, than the non-genre short fiction should be included as well per our policy. Given your question is under this topic, I assume it was based on the edit by Vasha77 that you have on hold? If so, than if it's agreed that Shirley Jackson is above the threshold, that edit is valid per our current inclusion policy. -- JLaTondre (talk) 15:35, 7 January 2017 (UTC)
Makes sense. That was the submission, and I have accepted it. Thanks for the feedback. --MartyD 11:56, 9 January 2017 (UTC)

Zac Brewer

Zac Brewer has changed his name since coming out as trans. He has many publications as Heather Brewer, only a few as Zac. But not only is he no longer using the name Heather, but he has also changed online references to him as much he could, and set up all-new websites under the new name. Therefore, I think we should make Zac Brewer the primary name and Heather the pseudonym. What do you say? --Vasha 23:17, 29 December 2016 (UTC)

It's a fairly common scenario: an author becomes known as A, then changes his or her primary working name to B for some reason. In most cases it has to do with marketing, but we also have a number of authors who changed their working names after a gender change, e.g. Hank Stine/Jean Marie Stine or Amos Salmonson/Jessica Amanda Salmonson.
As per Help, "For authors who publish under multiple names, the canonical name is the most recognized name for that author". Swapping VTs is somewhat time-consuming, so in most cases we wait until the new name acquires a critical mass of titles. Then again, sometimes old, abandoned names linger for years because no one is willing to spend the time necessary to rearrange everything, e.g. see Megan Lindholm who has been better known as "Robin Hobb" for the last 20 years. In the grand scheme of things it's not too important as long as all titles appear on the same Summary page. Ahasuerus 00:26, 30 December 2016 (UTC)
Actually, I think it is important to recognize the new identity when someone has come out as trans. And it really wouldn't take very much work just to variant all the HB books to ZB. Plus, we hope he has a long career; so it will be much harder to do this change in the future! --Vasha 00:34, 30 December 2016 (UTC)
Well, our "canonical name" values are not judgements re: SF authors' identity. Similarly, our "working language" values are not judgements re: SF authors' primary culture. We don't get paid enough to tackle such weighty issues :-) We just record author names as they appear in books and magazines and then pick the most recognizable name as the canonical value. It's similar to the way we determine canonical titles -- "the canonical title is usually the first title for that work, but may be a later title if that title is much better known". Ahasuerus 00:57, 30 December 2016 (UTC)
It is true that currently, someone is likely to pick up a book with "Heather Brewer" on the cover and consult the database to find out what else this author has written. What's the harm, though, if the answer they get is "this author also uses the name Zac Brewer, consult that page for other works"? At some point, presumably, the name Zac will become recognizable, though he just announced the change a few months ago. I just don't see the point of waiting some nebulous length of time... is it recognizable in two years, three, what? Might as well make the change now -- it's not like the page for Heather will be deleted entirely. --Vasha 01:08, 30 December 2016 (UTC)
If you feel strongly about it, you can always reverse the direction of the pseudonym and the variants. :) Bibliographies tend to be just that -- records of existing records. Annie 01:16, 30 December 2016 (UTC)
That is so -- and the Heather Brewer records will still exist, if we variant them to Zac Brewer (as we should). --Vasha 01:25, 30 December 2016 (UTC)
My only concern with making the change now -- rather than waiting until there is a critical mass of "Zac Brewer" books -- is that it assumes that there *will* be more "Zac Brewer" (SF) books. What if the author switches to mysteries or stops writing altogether? At some point we'd have to decide that it's been "long enough" and go back and change the VT/pseudonym direction again. It's not a huge deal either way, but it seems safer to wait. Ahasuerus 01:27, 30 December 2016 (UTC)
Z. Brewer has currently one short story and one novel, but has announced two more novels coming out next year (both speculative). --Vasha 01:40, 30 December 2016 (UTC)
It's encouraging that they will be speculative -- the fact that the only novel that has been published as by Zac Brewer so far contained no known speculative elements had me a bit nervous. Barring another industry meltdown like the one we had in 2008-2009, we should be most likely safe making the proposed change. Ahasuerus 02:05, 30 December 2016 (UTC)
OK, how about waiting until one of those books actually appears, then? --Vasha 04:06, 30 December 2016 (UTC)
Sounds like a plan! Ahasuerus 04:10, 30 December 2016 (UTC)

(unindent) I also think that sounds like a good idea. We don't always follow the preferences of an author, such as those that have been asked to be removed, or to have a particular item removed, or those who've asked to have birthdays removed (when they are public data). Gendered names are a bit different though, and I think we should normally follow an author's preference when it comes to such a name. But I think it's also appropriate to wait until that name has "announced" to the SF community, e.g. through a genre book with their new name. For example, Amos Salmonson was *living* as Jessica for about a year before making a formal announcement of her change -- which happened in "Mom's Home Made Apple Fanzine" in 1974 when she published a particularly feminine picture of the person that "Amos" had become. Most such announcements aren't quite as easy to pin down to a particular date, but publishing two genre books under his new name would certainly do that. Chavey 17:27, 30 December 2016 (UTC)

I think the biggest problem with following the author's preferences in a certain subset of cases is that there are other, equally compelling, subsets of cases. For example, take an author who has gone through a very painful divorce and wants to have as little to do with her old married name as possible. Or take an author who has been forced to use a pseudonym because the books published under the original name didn't sell well and whose resurrected career is still hanging in the balance. She may well see anything that promotes the pseudonym as helping her career to survive and vice versa.
It's all understandable and justifiable, but if we start making exceptions for "worthy causes", it will be very hard to preserve any kind of objective standard. Ahasuerus 18:22, 31 December 2016 (UTC)
I would go so far as to say the ISFDB "cause" is a "worthy" one and thought we might recognize others and attempt to not ignore such, for our project our standards must come first. For the reasons mentioned above, the most common name is still the older one (until a large body of in-genre work changes that). Uzume 03:21, 6 January 2017 (UTC)

Malzberg's Gather in the Hall of the Planets

We have this as a NOVEL, but by all calculation that I made it really can only be a NOVELLA by our standards: even with 300 words per page (which I'd doubt) in its first publication this wouldn't add up to 40,000 words that'd be necessary to characterize it as a NOVEL. It also doesn't stand up to that size with the German publication from 1985. Are there any differing (higher) calculations (else I'd make the necessary transformation)? Stonecreek 14:24, 30 December 2016 (UTC)

Improving our support for diacritics in author names

As per this discussion, our software considers character pairs like "Ó"/"O", "í"/"i" and "é"/"e" identical. For this reason the fact that we have a "Salvador Dali" author record on file means that we can't have a "Salvador Dalí" author record -- the software thinks that they are the same name and duplicate names are not allowed. Note that this only applies to non-English West European characters. Other similar characters are not affected, which is why we have a record for "Stanislaw Lem" as well as a record for "Stanisław Lem".

The current software behavior is inconsistent and frequently forces us to use compromises and workarounds when dealing with diacritics in author names. It's been suggested that we change the software to allow both "Salvador Dali" and "Salvador Dalí" at the same time. (The plan is to keep the lookup algorithm case-insensitive so that when an editor submits "robert a. heinlein", the software will realize that we already have "Robert A. Heinlein" on file and use that record instead of creating a new one for "robert a. heinlein".)

I have run a few experiments and tweaked some parts of the software on the development server. At this point I am 90% sure that we can change the code to support both "Salvador Dalí" and "Salvador Dali". A search on either "Salvador Dalí" or "Salvador Dali" will find both author records. It won't be a trivial change and it will require careful testing, but I think it's doable.

The only downside that I have found so far is that there will be a slight overhead when displaying submissions containing many authors. The current algorithm hardly takes any time at all to look up an author record when displaying a submission. With the new way of doing things it will take something like 0.04 second per author, which will mean 1+ second delays when displaying a submission with 30+ authors. Luckily, it doesn't happen very often and the trade-off appears to be worth it.

If there are no objections, I will start working on the proposed change once I finish processing the latest round of Fixer submissions. Ahasuerus 22:23, 30 December 2016 (UTC)

That will be a nightmare in terms of pseudonyms. Let's take this diacritically-challenged author. He's usually given as "Hervé" (even in the vast anglo-saxon world like here) but, sometimes he's been changed to "Herve" (like here). If I understand it correctly, the proposed change would mean that we'll have two authors (Hervé and Herve) that will have to be pseudonymistically linked with the correct varianting done. Hervé (or is it Herve) Hauck 19:15, 31 December 2016 (UTC)
That's right. It will be similar to the way Stanisław Lem's Summary page currently looks: Polish titles use "Stanisław" while translations use a mix of "Stanisław", "Stanislaw", "Stanislas" and " Stanislav" depending on the publisher's/translator's whim. Ahasuerus 20:11, 31 December 2016 (UTC)
Imagine the work and the look of the author's page (note that I'm already quite displeased by such pseudonyms settings (Liu Cixin being a pseudonym of Cixin Liu). Hervé (or is it Herve) Hauck 19:15, 31 December 2016 (UTC)
The "Liu Cixin"/"Cixin Liu" situation is temporary. The canonical name will be soon changed to "刘慈欣" and the two Romanized forms of the name will become pseudonyms. Ahasuerus 20:06, 31 December 2016 (UTC)
I'm completely against this move.Hervé (or is it Herve) Hauck 19:15, 31 December 2016 (UTC)
Another thing to consider is that some authors have nearly-identical names, the only difference being an accented character. A while back we ran into a couple of Dutch (?) authors whose names were something like "Peter Frai" and "Peter Fraï" (I don't recall the details), which we had to disambiguate with a "(I)". Ahasuerus 20:26, 31 December 2016 (UTC)
As a general observation, one of the long-term goals of this project has been to get as close to the "exactly as stated" standard as possible. We have found that everything works much better when we capture things as they appear in publications and handle the rest using variants/pseudonyms/etc. It's not always feasible, e.g. we wouldn't want to create a pseudonym/variant for all-lowercase and all-uppercase forms of author names/titles, but it has been the general direction of the project. Ahasuerus 20:34, 31 December 2016 (UTC)
To keep on this general level, that goal is commendable but, as I wrote before, I was at first strongly convinced by this approach, but very quickly I was confronted to such concepts as "case regularizations", "publisher regularizations", "initial regularizations", "space regularizations", "Ranks, suffixes, prefixes regularizations", "ellipsis regularizations" (to name a few, with some that appear here) that are not really conform to our "exactly as stated" professed standard. I was even called to order for entering a title as it was ("It's a typo" was the answer). That's why I frankly doubt that "exactly as stated" IS in reality the general direction of the project. The real debate to have is in fact to decide which of our idiosyncrasies we keep. Hauck 10:47, 1 January 2017 (UTC)
It's certainly true that we have added many caveats to the "exactly as stated" standard over the years. Some of them were due to software limitations. For example, the software supported only one publisher per publication, so we needed to have special data entry rules for publications associated with multiple publishers (like various book club reprints.) Similarly, there was no separate field for imprints, so we needed to have rules for squeezing imprints and publishers in the same field. The list goes on.
In addition, we wanted to avoid data fragmentation, which is also related to software limitations. Since there is no "variant publisher" mechanism, entering publisher names exactly as they appear on title (copyright?) pages would have created a lot of "publisher names" per actual publisher, making it hard to see what the publisher has actually published. Hence the "publisher regularization" rules.
Finally, some regularization rules were created (and sometimes enforced in the software) in order to facilitate searching and other types of user experience. The "ellipsis regularization" rules were among them.
Having said that, I should also point out that we have been slowly enhancing our software to allow closer compliance with the "exactly as stated" standard without adversely affecting user experience. For example, take the process of adding "transliterated titles/names" in 2015-2016. Users who don't know Kanji/Cyrillic/etc can still search on transliterated titles/names and see them in mouse-over bubbles while the primary data is now entered "exactly as stated", i.e. using the original script/alphabet.
It's a slow process, but if we continue pushing the software in that direction, we should be able to eliminate more and more "regularization" rules over time. Ahasuerus 22:36, 1 January 2017 (UTC)
I like the idea of having the author name as is but I do agree that the author pages are getting crazy. Maybe we need another user preference that hides all those "as by" from the author summary page. Incidentally Annie 11:46, 1 January 2017 (UTC)
Let me make sure that I understand the proposal correctly. Would this user preference suppress the display of "as by Pavel Vejinov", "as by Pavel Vešinov" and "as by Pawel Weshinow" on Павел Вежинов's Summary page but keep the translated titles intact? What about Robert A. Heinlein's Summary page? Would it make the line which currently reads "Life-Line (1939) [as by Robert Heinlein]" disappear since the canonical title is "Life-Line", i. e. the same as the variant? Ahasuerus 22:02, 1 January 2017 (UTC)
Yes for the Вежинов - all non-Latin-1 authors pages look overloaded now because of the too many English/German/French/Dutch titles we have. And we add more Russian/Bulgarian/Japanese titles, the Latin-1 ones will get in that direction (which is what Herve is also talking about I think). Annie 22:39, 1 January 2017 (UTC)
If the issue is that author pages can become too busy due to translations, wouldn't the user's response be to go to User Preferences and either turn off all translations or select a subset of languages that he or she is interested in? Ahasuerus 23:13, 1 January 2017 (UTC)
But I want to see all the translations - I just do not want to see whatever pseudonym was used for the specific variant. Annie 23:42, 1 January 2017 (UTC)
Plus if you only leave English and German for example on Lem's page (or any non-Latin language one), every single line will have "as by". Which makes the page really crowded. Same if I leave only Russian and Bulgarian on a Latin-1. Annie 23:57, 1 January 2017 (UTC)
Well, it depends on the number of translations. Коста Сивов, a Bulgarian author, hasn't been translated -- as far as we can tell -- so his page looks pristine. On the other hand, someone like Lem will have a lot of "as by"s. I have never thought of it as an issue, but I guess suppressing the "as by" component would make the page easier to read. I don't think it should be hard to implement -- please go ahead and create an FR. Ahasuerus 01:17, 2 January 2017 (UTC)
Right, I need to go figure out what my account used to be there :) Annie 01:54, 2 January 2017 (UTC)
Shouldn't be a problem -- our SourceForge settings let anonymous users create FRs and Bug reports. Ahasuerus 01:57, 2 January 2017 (UTC)
Ah, did not realize that. Thanks! :) Annie 02:00, 2 January 2017 (UTC)
One more note - people coming to the DB for the first time (no account, so no preferences) - they do not have languages filtered. And the page just looks... very busy. If I see that, chances are, I will go and look elsewhere for a list of Lem's works for example... This problem had gotten worse since we added the language support for authors. Annie 01:54, 2 January 2017 (UTC)
Users who are not logged in see the following message on Summary and Series pages:
  • Showing all/no translations. [Cookies-based button which lets them turn translations on and off] Registered users can choose which translations are shown.
One click of a button and all translations go "poof"! Ahasuerus 02:00, 2 January 2017 (UTC)
Again - the problem are not the translations but the "as by" on every single line in some cases. Annie 18:07, 4 January 2017 (UTC)
I guess we could add another cookies-based button to let unregistered users eliminate all "as by"'s, but I think that level of customization really ought to be handled via User Preferences. Ahasuerus 18:48, 4 January 2017 (UTC)
I am not sure for the Heinlein case - if the title, language and year are the same, we can as well not show it (we have the variant because of the name change). However - if it has titles under both variants, we need a way to filter under the other variant only so I suspect we need to have it there. Or have a "show all variants" link. Annie 22:39, 1 January 2017 (UTC)
- I would also love to be able to see a list of works under a pseudonym without the need to go for "show all works". Annie 11:46, 1 January 2017 (UTC)
Could you please clarify? Each pseudonym should have a "or view all titles by this pseudonym" link on the "See: [canonical name]" line. Are you seeing something else? Ahasuerus 21:55, 1 January 2017 (UTC)
They are there but in the merging/searching format as opposed to just a list (as on the main author page). So I cannot find out a glance which books from a series are available under the pseudonym (and for some languages this will mean under the language) Annie 22:39, 1 January 2017 (UTC)
Ah, I see. I think I looked into this issue a while back but gave up due to various complexities associated with creating a "pseudonym-only" bibliography page. I am sure it's possible given enough man-hours. If you find this functionality useful, please go ahead and create an FR. Ahasuerus 23:08, 1 January 2017 (UTC)

(unident)I think this will be good in the long run. In the short term, it will be a pain as everything is adjusted to meet the updated standard, but supporting Unicode (I'm assuming that's what's being changed, since it would allow for the differences in letters) is the way things should go. I'm not bothered by the pseudonym listings on author pages. ···日本穣 · 投稿 · Talk to Nihonjoe 17:35, 1 January 2017 (UTC)

Actually, the proposed change can be implemented without converting to Unicode. The database and the software are not quite ready for the conversion at this time, although it *is* on the list for a number of reason. For example, it will improve searches which include non-Latin characters. The way things work now, a search on "Асен" finds Асен Милчев, but a search on "асен" doesn't because the software has no way of telling that the Cyrillic "A" should be treated the same as the Cyrillic "а" for search purposes. Ahasuerus 21:50, 1 January 2017 (UTC)
I look forward to that day. There is a similar problem in searching for items in Japanese via kana aliases. As I understand it the only way around this currently is to search for all strings and/or create many transliterations. Uzume 11:24, 4 January 2017 (UTC)
Did you mean romaji instead of kana?--Rkihara 16:51, 4 January 2017 (UTC)
No, I mean kana. Though kana is used directly in Japanese so is kanji and even natives do not always know how to pronounce such depending on context, etc. Thus, kana is used as a means for a pronunciation guide and for indexing. As such, it is thus a form of transliteration. Romanji is just a set of Latin-based transliterations of Japanese. I am sure Russian speakers would appreciate Cyrillic transliterations of Japanese names and titles too (e.g., see wikipedia:Cyrillization of Japanese). To get back on topic, I just meant to search via kana one needs transliterations for such. Uzume 15:18, 5 January 2017 (UTC)

Disappearing cleanup reports

The number of cleanup reports dropped significantly in the last few hours. For example, Japanese Titles with a Latin Author Name, which had over thirty items on it (including several for which I could find no Japanese) earlier today, is no longer there. Did something happen to all the cleanup reports? ···日本穣 · 投稿 · Talk to Nihonjoe 06:20, 2 January 2017 (UTC) they all seem to be back. Maybe I caught it when it was updating all of them? ···日本穣 · 投稿 · Talk to Nihonjoe 06:21, 2 January 2017 (UTC)
Yup. Regeneration time starts at 1 am eastern US time and finishes about 30-40 minutes later. Annie 06:28, 2 January 2017 (UTC)
Been there—done that. It is disturbing looking at and whittling down the list to see it suddenly empty and then refill but apparently that is our reality. Uzume 03:24, 4 January 2017 (UTC)
Yes, that's how the cleanup system was designed to work. However, there is nothing preventing us from improving it if we can come up with a better approach! :) Ahasuerus 04:30, 4 January 2017 (UTC)
I would have to look into how the report results are implemented and stored but we could have it so new results overwrite the old results only upon completion, thereby never leaving a period of time when there are no results available (and thus removing the experienced disconnect). Uzume 11:18, 4 January 2017 (UTC)
They are missing for 30 minutes at the most (for the last reports). I suspect that there are a lot of other places where developer time will be better spent... And as someone that works on these a lot - I prefer them disappearing and then showing up slowly than having the old one (and working off it) and having it all replaced in a second on me. This way I know when to back off and wait for the new ones and do not end up with a "so what had I gone through now" when new values get added. But it may be just me. :) Annie 20:09, 4 January 2017 (UTC)

Preface to Mary Shelley's "Frankenstein"

The preface to Mary Shelley's "Frankenstein" ends with the "signature": "Marlow, September 1817". This has been incorrectly interpreted in several of our records (11 publications) as if the name "Marlow" were a pseudonym for the true author, who is otherwise unstated (although usually believed to be Percy Shelley). In fact, the Shelleys had moved to the town of "Marlow" in March 1817, where they lived until March 1818, and this "sign off" is simply a statement of where and when the preface was written (as happens with many other similar essays). I have put some additional detail in the Percy Shelley preface record. Unless there is objection, I would like to change this title and this title from an authorship of "Percy Bysshe Shelley (as by Marlow)" to an authorship of "Percy Bysshe Shelley (as by uncredited)". This affects verifications by me, MLB, Chronsf, Gzuckier, Syzygy, Mhhutchins, Don Erikson, and Bluesman (3 times). Chavey 05:20, 3 January 2017 (UTC)

That sounds like the right move to me. Good find. Uzume 03:27, 4 January 2017 (UTC)
Completed. Chavey 13:30, 7 January 2017 (UTC)

Container Titles without a Language - 2017-01-03 update

We are down to 82 Omnibus titles without a language. I believe all of them are English titles.

I have modified the report to include collections. The updated data will be available tomorrow morning. There are about 2,000 language-challenged collections, almost all of them English. My cursory review found only one non-English collection by Harlan Ellison, but there may be a few more. If a volunteer editor(s) could review the list looking for other non-English collections, it would be great. Once we are confident that only English collections remain outstanding, I will set all language-deficient omnibuses and collections to English programmatically. Anthologies will be next. Ahasuerus 02:48, 4 January 2017 (UTC)

I wonder if all the various reports are really still necessary after things have stabilized (which might not yet be applicable here but certainly should be for some older things). As an example, eventually could this "report" not just degrade to a pre-canned search link? Uzume 03:30, 4 January 2017 (UTC)
If it is empty, it will not show up. Annie 03:43, 4 January 2017 (UTC)
That's right. You can also access our full list of cleanup reports, although I don't recall if non-moderators can see all 195 of them. Which reminds me that I need to make more of them available to non-moderators. Ahasuerus 04:29, 4 January 2017 (UTC)
Being run will catch any new titles that somehow end up in that situation - and having them nightly means that noone needs to remember to check the pre-canned link... Just thinking aloud Annie 03:43, 4 January 2017 (UTC)
True. Unfortunately, some reports lock certain sections of the database which means that the server appears to be unresponsive while they are running. It would be beneficial to take a closer look at the timings and determine if we can improve certain things. Ahasuerus 04:29, 4 January 2017 (UTC)
Make some of them weekly or monthly once they are down to one or 2 entries every few days/weeks? Annie 04:33, 4 January 2017 (UTC)
Sounds like a good idea! Ahasuerus 04:44, 4 January 2017 (UTC)
I can look through all the omnibuses, chapbooks and collections this evening and clear the non-English ones out so that everything else can get assigned automatically. Annie 18:17, 4 January 2017 (UTC)
All OMNIBUS editions in the language challenged report over here are English and can be set automatically. Collections check - tonight. Annie 18:46, 4 January 2017 (UTC)
Or during lunch. 2 non-English found and already updated; everything else is in the clear and can be set to English. Annie 19:28, 4 January 2017 (UTC)
Great, thanks! Ahasuerus 19:32, 4 January 2017 (UTC)
Without the 4 I had open and never submitted that is - done now. :) Will do one more visual pass just in case but we are good to go. Annie 19:34, 4 January 2017 (UTC)

Show printing on title list page

A proposal for the list of works on a page. Look at this page. The verified edition is 4th printing. When I look at the page, I see two entries with the same price and the same ISBN and publisher (or more than 2 for the some more popular works). The only way to find out if I need to clone or can verify one of the existing ones will be to open each one to see if my printing is there by any chance... Any way to add "printing" somewhere more visible on the list? Annie 18:16, 4 January 2017 (UTC)

It sounds like the functionality requested in FR 794. I don't think there were any objections when it was proposed. Ahasuerus 18:51, 4 January 2017 (UTC)
Yes, did not find it when I looked. Annie 19:10, 4 January 2017 (UTC)

Server downtime 2017-01-04 @8pm

The server will be brought down for automated language assignment at 8pm server time. Estimated downtime less than 5 minutes. Ahasuerus 00:38, 5 January 2017 (UTC)

The server is back up. Over 12,000 titles have had a language code auto-assigned. Next I will update the cleanup report to include anthologies and chapbooks. Ahasuerus 01:06, 5 January 2017 (UTC)
Yey! We are getting there :) Annie 01:15, 5 January 2017 (UTC)
Indeed! The cleanup report has been updated and the results will become available tomorrow morning. I expect that it will find a bit over 1,000 anthologies and around 1,000 chapbooks. Ahasuerus 02:00, 5 January 2017 (UTC)
All remaining OMNIBUS editions on the list are English. I'll clear the non-English CHAPBOOks next (probably over the weekend). Ready to list languageless EDITOR records after that? :) Annie 18:27, 6 January 2017 (UTC)
I thought the omnibuses were taken care of in the last patch. Did you, by chance, mean anthologies? Ahasuerus 21:21, 6 January 2017 (UTC)
*sigh* I do need more coffee apparently. Anthologies - yes. All 903 of them. Sorry. Annie 21:23, 6 January 2017 (UTC)
No worries and thanks for working on them! I will update and re-run the script later tonight. Ahasuerus 21:53, 6 January 2017 (UTC)
They are a good distraction when I get tired of making Finnish and Italian variants and fixing weird language assignments for the multi-language report :) Annie 22:51, 6 January 2017 (UTC)
Chapbooks are all clear for automatic English assignment. A few suspicious ones were verified to be English indeed and a couple got their language assigned differently. Annie 18:07, 8 January 2017 (UTC)
Thanks, I will take care of them in another hour or two. Ahasuerus 00:10, 9 January 2017 (UTC)
Would you also update the report to pull EDITOR records with no language? That should get a lot of short stories taken care of when they are cleared. Annie 00:42, 9 January 2017 (UTC)
That's right. The first patch will take care of chapbooks. The second one, which I expect will be installed around 9pm, will add EDITOR titles. I need to re-run nightly processing on the development server first, which takes a while. Ahasuerus 00:52, 9 January 2017 (UTC)
Done. Ahasuerus 01:47, 9 January 2017 (UTC)
All EDITOR records are English. So they need some languages assignment :) Annie 07:31, 9 January 2017 (UTC)
Thanks! I have started a new section to discuss the rest of the title types. Ahasuerus 16:14, 9 January 2017 (UTC)

Common name

What should be the common name (and main pseudonym) for this guy: here. Born in what was the Russian Empire, technically Lithuanian and lived in the USA for the last 20 years or so of his life. Do we use his Russian name or his Lithuanian name or his English name as his main name (and as his legal name come to think of it)... PS: Here he is Annie 00:00, 6 January 2017 (UTC)

We typically use the most common in-genre name, e.g. "Vladimir Nabokov" rather than "Владимир Набоков". In this case the challenge is that the spelling used by the Italian publisher responsible for his only known genre credit is unorthodox: "Mistislav Dobuzhinsky" instead of "Mstislav Dobužinskij" (Italian) or "Mstislav Dobuzhinsky" (English). I would suggest using "Mstislav Dobuzhinsky" as his canonical name and creating a VT/pseudonym. That way anyone looking for "Mstislav Dobuzhinsky" will be able to find him. Ahasuerus 00:53, 6 January 2017 (UTC)
Yeah, this is why I asked - because of that weird spelling - if his first name was properly spelled, I would have left it alone and left it as is. That sounds like a good plan. :) Thanks! Annie 01:43, 6 January 2017 (UTC)

Server downtime - 2017-01-06 @8pm

The server will be brought down at 8pm server time for another language assignment iteration. Ahasuerus 00:08, 7 January 2017 (UTC)

The server is back up after 4,000+ auto-assignments. Ahasuerus 01:05, 7 January 2017 (UTC)

Queue for Changes to Verified Pubs?

There’s a lot of variation in what changes a Primary Verifier will allow to pass without notification. Because of this, I’ve been thinking that it might be a good idea for changes to verified pubs to be automatically put in a special queue for a short period, maybe 2-3 days to allow the top level, active Primary Verifier of the pub to put a hold or pass on the changes. If there are no active verifiers or holds, then the pub passes to the submission queue. Changes by Primary Verifiers to their verified pubs go straight to submissions.—Rkihara 17:31, 7 January 2017 (UTC)

A few questions to make sure that I under the proposed functionality:
  • How will the pub's primary verifiers be notified about the proposed change? (I assume that all of them will need to be notified since there is no way of telling who is active)
  • Will only one of the primary verifiers be able to put a submission on hold?
  • Will moderators have the ability to approve these types of submissions regardless of their status?
Ahasuerus 15:54, 8 January 2017 (UTC)
  • I thought that a pass/hold option could be added to the new verifier notification feature.
  • If there's no way of telling who's active any primary verifier will do.
  • The verifier placing the hold would have to clear it for it to enter the submission queue, where it is subject to moderator approval.
  • I'm now thinking the window to hold a verified pub should be no longer than 24 hours to keep things from backing up.--Rkihara 17:58, 8 January 2017 (UTC)
Verifier notification pages are updated when a submission is approved. What you are proposing is a mechanism that would prevent submissions from being approved -- for at least 24 hours -- if the affected pub has at least one primary verification associated with it.
I think the biggest problem that we have with changes to verified pubs is that there is no way of telling what the data looked like prior to the change. If there was, then a primary verifier could easily go back, check what was changed and revert the changes if needed.
Unfortunately, a "history" system would be difficult to implement. Simple fields like "price" and "ISBN" would be easy. Contents items would be the hardest part. Not only can a submission add or edit titles, but it's possible for some of the affected titles and authors not to be in the database at some future point. A history system would have to capture a snapshot of each publication record before and after the change. That's a lot of work. Ahasuerus 00:27, 9 January 2017 (UTC)
Could a manual summary of the changes made to a verified pub be made mandatory by blocking submission to the approval queue unless something is entered into a change history field? We're already leaving notes on the primary verifier's discussion page.--Rkihara 17:07, 9 January 2017 (UTC)
Just for the record, note that in your updates to Astounding/Analog you're leaving notes on the pages of clearly inactive verifiers (Hall3730‎, Davecat, Alibrarian, Boxen) and not on those of the "active" verifiers, which is, IMHO, not very useful. Hauck 17:32, 9 January 2017 (UTC)
That's true, I'm in the habit of leaving notes with Primary 1, since there were no other primaries when I started. That's why having a mandatory change field associated with the pub would be better. It doesn't matter who's active.
For the record, I originally filled in the missing data for lot of these magazines without checking off as the verifier, then worked with Swfritter double check his verifications. Now that I'm going through again, I'm taking a primary verifier slot if open. That makes me an active verifier, and I also recheck the contents.--Rkihara 18:08, 9 January 2017 (UTC)

(unindent) So basically make the "Moderator Note" field mandatory in the "Edit Publication" form if the publication has been primary-verified? And then make sure that the value of the Moderator Note field is displayed when the primary verifier views the submission that modified his or her verified pub? If so, then yes, it's doable and relatively easy to implement. Ahasuerus 18:35, 9 January 2017 (UTC)

I was thinking of a permanent change history field, along the lines of the bibliographic field. This would allow anyone to see what modifications have been made to a pub over time.--Rkihara 18:53, 9 January 2017 (UTC)
Oh, a new "change history" field in publication records? And make it mandatory to add something to it when editing a primary-verified publication? Ahasuerus 18:58, 9 January 2017 (UTC)
Yes, that's what I was thinking of. That way there's no time limit to review changes and they're all in one place, rather than scattered across the discussion pages of the primary verifiers. I suppose there could be problems with merges?--Rkihara 19:42, 9 January 2017 (UTC)
Unlike titles, publications can't be merged, so that shouldn't be an issue.
My tentative take on this issue is that it should be doable. We will have to add a "Change Summary" field to Edit Pub and then to Import/Export and Remove Title. The field will be required for primary-verified pubs and optional for all other pubs. It will be maintained as a change log, with each change record capturing the following information: publication ID, submission ID, editor ID, editor-entered change summary. Publications will have a "View Change History" link which will take the user to a new Web page displaying this information as a list or a table.
This approach will allow editors to explain not only the "what" of each change, but also the "why". Currently this information is either not entered at all or entered in the "Moderator Note" field, which is transient. Of course, the approving moderator will need to make sure that the explanation makes sense, but that's to be expected. Overall I like it. Ahasuerus 00:26, 10 January 2017 (UTC)
I'm against this move. Adding another mandatory field is, IMHO, 1) useless as the moderating process and the obtaining (is this word english?) of pertinent information seems a quite streamlined process for the moderators that actually moderate the bulk of the submissions, 2) superfluous as the principles of notification are quite clear and just need to be collectively enforced, 3) counterproductive as this will raise another barrier to the entrance of new contributors, the entering of data is complex enough that we should aim for simplicity and ease. Hauck 08:04, 10 January 2017 (UTC)
(I would use "the obtaining".) A half-baked, pre-coffee thought: How about a slightly different approach? If there were a way to "publish" a submission to the primary verifier(s) -- prior to acceptance -- and those verifiers had a way to look at the submission and either to indicate approval/disproval or simply comment on it, that might streamline a lot of communication (and research) for moderators and for editors. The submission could also have something to indicate it is so published. Original submission could make this an additional option (i.e., a submit + publish) -- perhaps a checkbox toggled on by default for anything with primary verifiers? And the moderator review screen could also provide a way to do it. Notification to the verifiers could use that same new change notification mechanism. --MartyD 12:46, 10 January 2017 (UTC)
One other negative aspect will be a general slowing down of the approval process, either creating possible edit conflicts or simply discouraging potential contributors. To be frank, I don't really see what is the problem with the present moderation and notification process (it seems to work OK, without mishaps and with a correct communication level) but perhaps am I to immerged in it to see it from outside. Hauck 13:15, 10 January 2017 (UTC)
Looking at the first line, the original problem was the variety of things that verifiers allowed to pass without notice. The new schemes seem to be treating all changes as the same for all verifiers, leaving the onus on them to filter. The desire to avoid stalling the system means that verifiers who log on every few days will be bypassed anyway. Another sideways look at this is to add flags of various sorts for verifiers (e.g. images) and the active indicator, which would be displayed with the list of verifiers so an editor knows who to notify? Doug H 14:35, 10 January 2017 (UTC)
The edit conflicts are already bad enough - that will multiply them badly. And the software is challenging enough when you start to add this to the nightmare. I understand people wanting to protect their data and so on but this is a shared platform. Can a snapshot of all OLD values be dropped into a column somewhere so the verifier(s) can go and explore changes if need be? I almost gave up the first few days (despite moderators being around and fairly active). Annie 15:49, 10 January 2017 (UTC)
The proposed change only ensures that you log your changes, which you are already supposed to do on the verifier's page anyway. This puts "all" of the change history in one place instead of scattering it across the pages of maybe five verifiers. How hard is it to do what you're already required to do?--Rkihara 17:26, 10 January 2017 (UTC)
When you change many records where I'm PV2 and where the PV1 is inactive and do not notify me, I'm not sure that's what is required. But it's probably peripherical.Hauck 18:17, 10 January 2017 (UTC)
More than one primary verifier is a recent change, so most change notices will be found in Primary 1. I put them in PV1 for that reason, one-stop checking, instead having to look in PV1-5. Since the system flags you that I have made a change, a look in PV1 will find the note. There is no hierarchy in verification, and if there should be it seems that the "last" PV is the one that should notified if there is a change-as they've had the most recent look at the pub.--Rkihara 19:51, 10 January 2017 (UTC)
If you think that you're allowed to ignore our standard (and stated visibly on every unactive verifier's page) procedure "Otherwise, please post notices and inquiries only on the talk pages of the other primary verifiers." because you don't feel so, it's useless for you to talk about (I cite you) to do what you're already required to do.Hauck 08:49, 11 January 2017 (UTC)
Okay, since I'm making myself a primary verifier, if not already, I'll post it on my page.--Rkihara 09:00, 11 January 2017 (UTC)
People were talking about holding submissions for PVs to review - that is what I had been commenting about. Notifications of any type are not a problem of course Annie 17:55, 10 January 2017 (UTC)
The idea of holding the submission was abandoned and the discussion has moved down another path.--Rkihara 18:10, 10 January 2017 (UTC)

(unindent) Re: "a snapshot of all OLD values". Unfortunately, it would require a significant effort. Granted, it would be easy to do for fields like "ISBN" and "Price". However, consider publishers. The way the database works, we store publisher numbers (1, 2, 3, etc) in publication records. Then, when we display a publication, we retrieve the name of the publisher, including its transliterated name(s), from other parts of the database and display them.

This works well when displaying current data. However, suppose we were to save a verified publication record as it existed prior to submission approval. We would store publisher ID 12345 in the saved record. Then, a few months later, publishers 12345 and 12346 are merged, so publisher 12345 no longer exists in the database. When the original verifier goes back to check this pub's history, there is no publisher 12345 to display. The same thing can happen to publication series, authors and titles. Actually, it can get even more complicated with authors and titles if we want to preserve the pseudonymous/VT/series relationships as they existed at the time.

The ultimate way to address this issue would be to build a snapshot of the then-current version of each about-to-be-changed Publication Web page and store it in a separate database location prior to submission approval. We could then have a list of snapshots for every publication and display them on demand.

Actually, checking the code, I see that it would be doable, although disk space may be a concern. Let's see. We have 784,600 Edit Pub submissions. Since 27.5% of our pubs have been verified, let's assume that 30% of Edit Pub submissions affected verified pubs. That's 235,000 submissions. Assuming 7Kb per verified publication (a mix of novels, collections, magazines and anthologies), that's 1.6Gb over a 10-year period. That's not really too bad and won't affect our disk space situation too much, at least not in the foreseeable future. So maybe it's doable after all. Ahasuerus 17:27, 10 January 2017 (UTC)

Maybe as a first step, not a full snapshot that has full links in all directions but just a snapshot of the submission as it shows on the left side (or just the red lines if possible). It won't contain changes in something done directly on publishers and internal titles but at least will have a story of what was in the field and will be better than it is now. Annie 17:35, 10 January 2017 (UTC)
I expect that a full HTML snapshot should be easier to implement than a partial snapshot. We started work on a "history" system -- basically a log of changed data -- in 2007. However, we quickly ran into the problems outlined above and more. I spent many man-hours trying to get it to work in the early 2010s, but eventually had to give up because the underlying approach was flawed. Ahasuerus 18:42, 10 January 2017 (UTC)
Ultimately, we need version control basically -- that is the only thing that will cover all changes from all sides :) But building that in a system not designed for it can be challenging. Annie 17:35, 10 January 2017 (UTC)
In a way, publication snapshots will be a versioning system of sorts. We'll need to add a warning about potentially broken links, but the textual part should be very close to what the data looked like as of the time of the edit. Ahasuerus 18:42, 10 January 2017 (UTC)

2017-01-08 downtime @8PM

The server will be unavailable between 8pm and 8:05pm server (US Eastern) time tonight. I expect that about 3,800 titles will have a language code auto-assigned to them. Ahasuerus 00:28, 9 January 2017 (UTC)

We are back up. Ahasuerus 01:03, 9 January 2017 (UTC)

2017-01-09 server downtime @ 11am

The server will be unavailable between 11am and 11:05am server (US Eastern) time. Approximately 4,500 titles will have a language code auto-assigned. Ahasuerus 15:40, 9 January 2017 (UTC)

The server is back up. Ahasuerus 16:03, 9 January 2017 (UTC)

Language assignment road map

Here is a breakdown of language-challenged titles as of this morning:

| title type   |    count |
| COVERART     |    19627 |
| INTERIORART  |     8764 |
| ESSAY        |     7457 |
| INTERVIEW    |      218 |
| NOVEL        |    36248 |
| NONFICTION   |     4407 |
| POEM         |      751 |
| REVIEW       |     2065 |
| SHORTFICTION |     6356 |

It looks like all (or almost all) of them are associated with NOVEL and NONFICTION publications. I plan to change the cleanup report to include NONFICTION titles next. Once they have been cleaned up, we can tackle NOVELs. We'll probably have to do it one letter at a time. The rest of the titles are in NOVEL and NONFICTION pubs and will be handled via auto-assignment. Ahasuerus 16:13, 9 January 2017 (UTC)

Can you pull a list of what publishers are those novels from? Maybe there are some that do not even need eyeballing them... Annie 16:28, 9 January 2017 (UTC)
Yes, publishers is something that I was going to look into. Also, it's very likely that the 10,400 novels whose title starts with a "The" are English. Ahasuerus 16:48, 9 January 2017 (UTC)
Yes, every single title I looked at that starts with "The " (with the space) was English. I think you can safely just set those to English. Also, look at prices - anything in pounds is English. US$ has a few Spanish ones just to annoy us but I do wonder if we cannot just set them to English and call it a day (and errors can be fixed later?). Annie 17:01, 9 January 2017 (UTC)
As I recall, a number of early non-US publications contained a US$ price due to the way the data was originally imported. A lot of them have been cleaned up/deleted over the years, so perhaps it's not a problem any more. I guess we'll have a better idea once we process the letter 'A'. Ahasuerus 17:41, 9 January 2017 (UTC)
"A" will be very English-slanted because of the indefinite article... I'd rather see "D" as a first letter (which will get the Die/Der/Das from German or "L" (for the French) which have better chances to actually have non-English  :) Annie 17:44, 9 January 2017 (UTC)
Oh yes, that's a good point. Ahasuerus 17:52, 9 January 2017 (UTC)

(inindent) A quick question - if a short story is in 2 collections and both collections are set to English, will your automation set the story to English too (provided that all that is in the collection is either English or not set)? While doing the Italian variants I keep stumbling on whole anthologies and collections where the containers are set to English but not all the stories are (or none in some cases) (because one of the containers is Italian most likely). So when I get the Italian out from the equation, will your script catch these and assign English to them? Annie 17:58, 9 January 2017 (UTC)

The script checks how many languages each pub is associated with. If it's 0 or 2+, then it ignores the pub. If it's 1, then that language is assigned to all language-less titles in the pub.
If a publication contains Italian and English titles, then the script will skip it. If and when an editor changes the pub to contain only English or only Italian titles, it will be processed by the script the next time it runs. HTH! Ahasuerus 18:29, 9 January 2017 (UTC)
Yeah, it did (for one case). An example: Senhor Zumbeira's Leg. The Italian pub should be out when my recent edit is accepted which should mean that this one gets its language set next time the script run, correct? I am figuring out if I can leave these alone or if I should set them to English while I am around :) Annie 18:35, 9 January 2017 (UTC)
That's right. I have tested it on the development server and the script assigned "English" to this title. Will the wonders of modern science and technology ever cease?! Ahasuerus 18:46, 9 January 2017 (UTC)
Great! Thanks for the confirmation. I just did not want it to be left behind and then to have to deal with it in 3 months again. Annie 18:48, 9 January 2017 (UTC)

(unindent) The cleanup report has been updated to include NONFICTION titles. The data will become available tomorrow morning. Ahasuerus 00:46, 10 January 2017 (UTC)

4357 English ones, 1 Spanish, 1 French. Once my pending are cleared, you can get the 4357 assigned automatically. Annie 17:22, 10 January 2017 (UTC)
Actually 4356 English and one in Klingon but as we do not support Klingon, English is the only option for it :). Unless if you want to add a new language "Other" which can be used for this and for any multi-language work. Annie 17:25, 10 January 2017 (UTC)
Great, thanks! I will re-run the script shortly. Ahasuerus 18:46, 10 January 2017 (UTC)
For the record: All "The " And "A " were English (still thinking on how to deal with the novels). Annie 19:24, 10 January 2017 (UTC)
Thanks. I have updated the script to auto-assign "English" to all language-less NOVELs and SHORTFICTIONs whose title starts with "The ". It should gain us almost 20,000 auto-assigned titles, which is nice. I plan to run it on the live server shortly. I will then update the nightly script to include NOVELs whose titles start with a "D" -- we'll see what it will find. Ahasuerus 19:34, 10 January 2017 (UTC)
Why don't you add the ESSAYs to the automated English for titles starting with "The " as well? The ARTs probably will also be ok (Interviews and Reviews can be cross-language (English books reviewed in FRench and vice versa) but the arts and the essays should be safe? And even the poems... Annie 19:38, 10 January 2017 (UTC)
Another good point. I have updated the script to include ESSAY and POEM titles.
I am a bit hesitant to handle COVERART and INTERIORART titles automatically because they seem to have a fair number of incorrectly assigned languages. Once we process the remaining 25,800 NOVEL titles, the auto-assignment process should take care of the rest. Ahasuerus 19:50, 10 January 2017 (UTC)
German novel with no language with a "The " cover with no language will end up as an English novel once the cover gets English and the Novel get assigned based on that. You are right, the arts will need to be after we deal with the Novels. What I was thinking of was a German novel with a set language with a cover with no language where the cover starts with a The which did not get assigned based on the novel because of something else in it blocking it. But these will wait a bit. Annie 19:57, 10 January 2017 (UTC)
Incorrect languages won't be fixed though - the only reason to be worried is the case above where a wrong assignment will also wrongly assign the title to a novel Annie 19:57, 10 January 2017 (UTC)
True enough. Ahasuerus 20:07, 10 January 2017 (UTC)
On the interviews (as we have only 218 language-challenged ones) - can you get them into the report tonight together with the "D" novels? Annie 19:57, 10 January 2017 (UTC)
Sure. There are only 108 interviews left. Here is where we stand right now:
| count(*) | title_ttype  |
|    13613 | COVERART     |
|     7274 | INTERIORART  |
|     4999 | ESSAY        |
|      108 | INTERVIEW    |
|    25827 | NOVEL        |
|      586 | POEM         |
|     1849 | REVIEW       |
|     4370 | SHORTFICTION |
Ahasuerus 20:07, 10 January 2017 (UTC)
My edit to ask you for a new breakdown got blocked by you posting a breakdown :) Would you like to update the multi-language report to include (no-language, language) as a valid mismatched pair as well? Or wait until we clear the novels so the language-challenged "The " arts can be handled as well? Annie 20:11, 10 January 2017 (UTC)
Well, once we finish the language assignment process, it should be impossible to create new titles without a language. At that point I will simply change "Container Titles without a Language" to "Titles without a Language" and wait to see if any new offenders pop up. I will also handle the infamous "Undefined" language. Ahasuerus 20:18, 10 January 2017 (UTC)
Which reminds me - can we get a list of those "undefined" so we can see what these are and get them to their proper languages? Annie 20:24, 10 January 2017 (UTC)
I plan to add them to the "Titles without a Language" report (see above.) Ahasuerus 20:43, 10 January 2017 (UTC)
Somehow managed to miss the last sentence. Sorry :) Annie 21:24, 10 January 2017 (UTC)
BTW, I was surprised by the number of language-less REVIEWs left -- surely we didn't have that many reviews in NOVEL publications? -- so I spot-checked a few. It turns out that they were parents of pseudonymously published REVIEWs. I guess it means that we will have to handle them and other pub-less titles manually. Ahasuerus 20:18, 10 January 2017 (UTC)
Yeah, we have a lot of stories, essays and arts like that as well (I kept finding them and finally realized why they are still around even when the child is ok - they are not part of a container - I do not think it is just parents of pseudonymously published - it is any parent which is not part of a publication and that was created before the mandatory language was added to the DB). Annie 20:24, 10 January 2017 (UTC)

(unindent) OK, the report has been updated to include interviews and "D" novels. The data will become available tomorrow morning. Ahasuerus 22:28, 10 January 2017 (UTC)

"D" novels are cleared. 2090 English ones and 1 German one (pending its language assignment now). I will look through the interviews in a bit. If you want to add another letter, I can look at it tonight. Can we try L or I (or both) - I am chasing other language definitive articles basically... If they end up having the same number of non-English, we may be looking at a very English dominated lists (not that this is surprising) Annie 17:26, 11 January 2017 (UTC)
Interviews cleared as well (as soon as my pendings are cleared and I can finish the varianting and language assignments there). 3 needed unmerging to pull German versions out from the English ones (same name), 105 are pure English. A few inside of novels, all the others were parents that are not part of any publication. Annie 18:09, 11 January 2017 (UTC)
Approved, thanks! There are 795 eligible "I" novels and 878 "L" novels. They will be out next guinea pigs. Ahasuerus 18:33, 11 January 2017 (UTC)
Last set of variants also submitted after the last unmerge. Do you also want to throw the poems into the mix so I can slowly start clearing them as well? There aren't too many of them. Annie 18:39, 11 January 2017 (UTC)
Sure. I am running the changes on the development server and plan to deploy them within the next hour.
BTW, I have identified a scenario which may result in the creation of a language-less title even after we finish the auto-assignment project. When cloning a publication, the logic uses the language of the original pub's reference title when adding manually entered titles to the database. However, if you clone a publication without a reference title, the logic defaults to "no language". It should be a very rare occurrence since we have a cleanup report that finds publications without a reference title, but it's possible. Ahasuerus 22:48, 11 January 2017 (UTC)
So once we are done with the major language assigning, let's have a report that find languageless titles - which will be mostly empty but will catch these as well. However - that also will mean that neither the editor, nor the moderator realized that the language is missing... So even of the software can do these, I hope we won't see a lot of them remaining lagging around. I tend to go and check all of my submissions once approved to make sure something like that does not need adjusting... Annie 23:47, 11 January 2017 (UTC)
We have been slowly expanding "Titles without a Language" to cover additional title types. The day we finish the auto-assigning project will also be the day the logic will be expanded to cover all title types -- which is what you are asking for :-) Ahasuerus 23:51, 11 January 2017 (UTC)
Ah, yes. You are right. I lost track of all the reports for a little while here :)
All of the 227 items in the cleanup report "Art Titles by Non-English Authors without a Language" are artworks in English-language publications. (except for no. 102 "Science Fiction. Five Stories = Science Fiction. Fünf Geschichten" which is the cover of a bilingual pub. with no assigned language) --Vasha 23:38, 11 January 2017 (UTC)
In this case I had been assigning the smaller language - so in this case put German. :) Or in case of more than 2, whatever the publisher language is. And so on.  :) Annie 23:47, 11 January 2017 (UTC)

(unindent) "L" and "I" novels cleared - 2 Italian, 3 Spanish and 1658 English one. As soon as my pending are accepted, the rest can get automatic language. Poems next. Annie 20:04, 12 January 2017 (UTC)

Poems cleared as well - all English. Most of them parents of variants or non-attached; a few are inside of novels and the rest are in the multilanguage works that are still not cleared. Annie 20:55, 12 January 2017 (UTC)
Great, thanks! Here is where we will be after the next iteration of auto-assignment:
| title_ttype  | count(*) |
| COVERART     |    11881 |
| INTERIORART  |     6960 |
| ESSAY        |     4906 |
| NOVEL        |    22037 |
| REVIEW       |     1849 |
| SHORTFICTION |     4337 |
Would you like to tackle reviews next? Or perhaps some subset of novels? Here are the new counts (non-alpha characters excluded):
| letter | count(*) |
| A      |     2149 |
| B      |     1697 |
| C      |     1641 |
| E      |      828 |
| F      |     1140 |
| G      |      892 |
| H      |     1017 |
| J      |      361 |
| K      |      432 |
| M      |     1512 |
| N      |      634 |
| O      |      590 |
| P      |     1096 |
| Q      |      103 |
| R      |     1056 |
| S      |     3030 |
| T      |     1582 |
| U      |      248 |
| V      |      412 |
| W      |     1273 |
| X      |       29 |
| Y      |       78 |
| Z      |      119 |
Ahasuerus 22:24, 12 January 2017 (UTC)
Reviews and the Q, X, Y and Z novels (the smallest groups so they are off our plate)? Annie 22:30, 12 January 2017 (UTC)
Sure, can do. Ahasuerus 22:57, 12 January 2017 (UTC)
If you have a trivial way to find the non-alpha ones as well, I'd take them - if not, they will come with the last letters. Annie 22:30, 12 January 2017 (UTC)
There are approximately 100 non-alpha language-less NOVEL titles. Once the alpha titles have been processed, I'll change the logic to include all language-less NOVELs. At that point all non-alpha novels will appear on the report. As Marty would say, "Magic!" :-) Ahasuerus 22:57, 12 January 2017 (UTC)
Which is why I said "trivial" :) They will show up in an All report so not too worried :) Annie 23:05, 12 January 2017 (UTC)
And we will probably need to split these short stories and essays into groups as well I suspect- most of them will be parents that won't get assignments from anywhere else and they are too many for a single list... Annie 22:30, 12 January 2017 (UTC)
I hope that a fair number of introductions, afterwords and excerpts will be auto-assigned, but there is no easy way of telling until we get there. Ahasuerus 22:57, 12 January 2017 (UTC)
If the ones I cleared so far are any indication, I would not hold my breath. Annie 23:05, 12 January 2017 (UTC)
Come to think of it, there is a way to tell by creatively abusing the development server. If I change the language of all unassigned NOVELs to English and re-run the auto-assignment script, it should give us a rough idea of what will remain outstanding. Let me give it a try...
OK, here are the post-NOVEL/post-REVIEW counts:
| title_ttype  | count(*) |
| COVERART     |     2219 |
| INTERIORART  |     5442 |
| ESSAY        |     4342 |
| SHORTFICTION |     4203 |
Not perfect, but I think it should be manageable.
In any event, I have updated the cleanup report to include reviews and the X,Y,Z novels. The data will be available tomorrow morning (or late at night for those on the West Coast.) Ahasuerus 23:59, 12 January 2017 (UTC)
Sounds about right on the textual ones. I wonder where all those INTERIORART are and why the automation does not handle them - we cannot have 5000+ parents out there, can we? Annie 00:08, 13 January 2017 (UTC)
Spot-checking suggests that some are parents while others appear in mixed language art books. Ahasuerus 00:58, 13 January 2017 (UTC)
Ah, those. I had been leaving them alone for now while clearing the rest of the multilanguage ones. Thanks for checking! Annie 01:06, 13 January 2017 (UTC)
X-Z novels are cleared - all are English. The Reviews will take a bit longer to clear :) Annie 18:41, 13 January 2017 (UTC)

Author Note field

Two items I just came across made me think that having a Author Note field would be useful to record information; see this submission which gives helpful source information for added info and this conversation about an author's language.

This type of information seems similar to how we document publications; I know we used to keep extra stuff like this in the Bibliographic Comments section of the Wiki, but it seems like we're moving towards including those things into the DB when they can be accommodated.

I didn't see a FR for this when I searched, but I could have missed it. Albinoflea 22:49, 9 January 2017 (UTC)

That would be FR 307, Move "Author" and "Bio" pages from the Wiki to the database.
The current plan is to:
  • finish the process of migrating Series/Publication/Publisher notes to the database proper
  • decide whether author records should have a single "Note" field or two fields, "Note" and "Biography"
  • implement the change
Ahasuerus 00:08, 10 January 2017 (UTC)
Ah... yes, that sounds familiar now. I must not have scrolled back far enough... Do we know how many existing Author Biography pages live in the Wiki? Albinoflea 01:34, 10 January 2017 (UTC)
As of last March:
  • Bibliographic Comments pages: 1,636
  • Bibliographic Comments Talk pages: 33
  • Biography pages: 1,896
  • Biography Talk pages: 1
Ahasuerus 02:05, 10 January 2017 (UTC)

2017-01-10 server downtime - 2pm and 3pm

The server will be down for the next iteration of language auto-assignment between 2pm and 2:05pm server (Eastern US) time. Ahasuerus 18:47, 10 January 2017 (UTC)

The server is back up. Ahasuerus 19:03, 10 January 2017 (UTC)
There will be another downtime at 3pm. It should only last 2 minutes and gain us about 20,000 auto-assigned titles. We are getting there! Ahasuerus 19:39, 10 January 2017 (UTC)
Everything should be back up. Ahasuerus 20:02, 10 January 2017 (UTC)

2017-01-11 downtime - 5pm

The server will be down for the next iteration of language auto-assignment between 5:30pm and 5:32pm server (Eastern US) time. Ahasuerus 22:05, 11 January 2017 (UTC)

The server is back up. Ahasuerus 22:32, 11 January 2017 (UTC)

Change in the publication view

Based on a small discussion here: here, here is a proposal for changing in the publications view. At the moment, when the variant of a title has a different language than the original, the software renders that as a translation in the publication content view. When the variant is an Interior Art, that does not look accurate. So the proposal is to treat is a variant and not as a translation so in Bilbon viimeinen laulu:
instead of
Bilbon viimeinen laulu • interior artwork by Pauline Baynes (trans. of Bilbo's Last Song 1990)
we will get
Bilbon viimeinen laulu • interior artwork by Pauline Baynes (variant of Bilbo's Last Song 1990)

Anyone with any opinion on this? Agreement? Disagreement? I do not care? Something else? Annie 00:08, 12 January 2017 (UTC)

That makes sense to me. Albinoflea 19:58, 12 January 2017 (UTC)
Sounds good. --Vasha 22:46, 12 January 2017 (UTC)
That's appropriate. While I know there are some instances of art with English text that has been converted to the same art with, say, German text, and hence should properly be viewed as a "translation", I believe that is rare, and could be handled by a note. Chavey 02:12, 13 January 2017 (UTC)
I'd think that shouldn't be so even in such a case: the moment we view something as INTERIORART we decide to drop the focus on the language; and a note like 'Involved text was translated by Gandalf Gremlin' would still be an option.
It'd be possible to view a comic or even a cartoon as SHORTFICTION (with illustrations), but I think there were good reasons to not pursue this line of thought. Stonecreek 07:05, 13 January 2017 (UTC)

(unindent) Looks like a consensus to me! The software change has been made and deployed. Ahasuerus 21:12, 13 January 2017 (UTC)

Poems not attached to publications

Before I submit deletions for the ones I am finding (a lot of them have no language assigned - which is how I am finding them), is there any reason to keep in the DB poems like this one: A Description of Morning when they are not part of a publication and are not a parent for a variant that is part of a publication. Thoughts? Annie 20:36, 12 January 2017 (UTC)

If it's a valid genre work, it should remain. It's possible to know a work is genre, but not have information regarding the specific publication. Ideally, there would at least be a note with some information why the record is present, but doesn't always happen. -- JLaTondre (talk) 21:08, 12 January 2017 (UTC)
I am not sure that some of the ones I saw were valid genre works but I'll leave them alone. I think we should at least have a "first published in" note for these... Annie 21:14, 12 January 2017 (UTC)
"A Description of Morning" is available on-line and is clearly non-genre. I deleted it. -- JLaTondre (talk) 01:40, 13 January 2017 (UTC)

2017-01-12 server downtime - 5:45pm

The server will be down between 5:45pm and 5:47pm server (Eastern US) time. Ahasuerus 22:25, 12 January 2017 (UTC)

Done. Ahasuerus 22:47, 12 January 2017 (UTC)

Fictionalized biography of Edgar Allan Poe

A question about inclusion / exclusion. We include non-fiction biographies of important authors. I couldn't find anything that seemed to address the issue of a fictionalized biography. The book "Dark Glory", by Dorothy Dow, is such a work. "A Companion to Poe Studies" says the book "confines its fiction principally to imaginary conversations and to narrative commentary and interpolation". At least one source I found lists the book as non-fiction, although it really isn't. Does this book belong in here? Chavey 02:07, 13 January 2017 (UTC)

If the truly non-fiction equivalent is "in", I'd say this should be, too. It's still about Poe. --MartyD 02:48, 13 January 2017 (UTC)
And I included such an item for H. G. Wells, because of his importance. Stonecreek 07:07, 13 January 2017 (UTC)
Thanks for the advice. Poe is certainly at a fairly high level of importance. I'll add the book. Chavey 05:40, 14 January 2017 (UTC)

Spanish speaking editor up for a challenge?

The stories here Fábulas need to be replaced with their Spanish variants. My google-fu does not seem to work very well for that one so can someone that speaks Spanish take a look and see if they can find the names of the stories and who translated each (if possible)? I don't even mind doing the varianting and replacing if someone can get the data and post it... Annie 20:15, 13 January 2017 (UTC)

I do not believe that the complete table of contents is online anywhere. [ Here] is one of the translated stories, but using its title as a clue didn't allow me to find the rest. If no one else speaks up, I will put in an ILL request; there's a copy at a public library in my state. --Vasha 21:20, 13 January 2017 (UTC)
Thus the challenge part of my question :) Thanks! Annie 21:31, 13 January 2017 (UTC)
It's a later edition from Lectorum, but I think this is the same collection. The prologue is dated Buenos Aires, 1983 (although it is credited to both Borges and Alifano). I will enter this edition and match the English and Spanish titles. We can see how its contents correlate with that other pub we have. --MartyD 12:30, 16 January 2017 (UTC)
The contents matched 1-for-1, so I swapped out all of the English titles for the Spanish. --MartyD 14:11, 16 January 2017 (UTC) / Request: Add The Witch Who Came In from the Cold

The February 3 issue of, which I have added, has a review of the first three episodes of the Serial Box serial The Witch Who Came In from the Cold (not yet in the DB). Now I am not sure how to add that serial; but their previous production Bookburners provides a model. Would anyone like to enter The Witch... into the DB and link the review to it? (Currently I have the article as ESSAY not REVIEW). --Vasha 02:44, 16 January 2017 (UTC)

Am I missing something? Why are we including's non-fiction? It is a blog, not a webzine. We include their fiction under the SFWA recognized market exception since it's by notable writers and/or frequently later collected in publications. I don't see the point of including their Batman, Star Trek, etc. rewatches and other non-fiction. Unless there is a downloadable version that I'm not aware of, we should be sticking to only the fiction. -- JLaTondre (talk) 11:35, 16 January 2017 (UTC)
that would make things easier... I have been entering everything on the assumption that it was being called a magazine. Are there other cases of something that is not a magazine where the fiction is entered? --Vasha 14:18, 16 January 2017 (UTC)
I know I have accepted some of these additions on the mistaken understanding that it's both the website and emailed newsletter. Upon further review, I see now the newsletter is something different. --MartyD 14:27, 16 January 2017 (UTC)
What exactly is the "periodical" that publishes the fiction? I think that ought to be clarified. There should be someplace in the DB to note that. If the stories are not being published in any periodical, how are they to be catalogued?
Here's a thought. These stories are always published individually as e-chapbooks. We do catalogue them in that form, as by the publisher (which also puts out novellas). Stories appear simultaneously on the blog and in chapbook form. If we decide that the blog is not a webzine, then maybe we should not list the appearances of stories there, but only their chapbook publication. --Vasha 20:19, 16 January 2017 (UTC)'s fiction was original entered (per my impression) as a webzine as we have no way to handle a blog and it was the closest thing. While they may also release them as ebooks now, that wasn't the case originally. For example, the first story we have indexed is After the Coup which was published on in 2008, but not released as an ebook until 2010. Treating the original posts as a webzine seems reasonable to me given our explicit criteria that we will carry SFWA recognized markets, but extending that to all their blog posts doesn't. A note can be added to the to explain how and why we are handling these somewhat differently than normal. I've put your current edits on hold pending further community feedback. If no one else argues for inclusion, I will go through and remove the non-fiction. Please don't take this negatively, we do appreciate your attempt to make the database more complete and accurate. -- JLaTondre (talk) 22:05, 16 January 2017 (UTC)
I vote for the deleting of the non-fiction. If we want to list every essay about SF available on the web, we're going to be flooded by the material (I'll be even able to enter the 600+ entries in my blog, great!). Hauck 18:32, 17 January 2017 (UTC)
I agree - do not have a webzine the way Strange Horizons does for example (their non-fiction is part of their webzine). As much as I like completeness, allowing these in opens the door for allowing reviews from non-genre media for genre books in and that will spiral out very fast. Annie 18:47, 17 January 2017 (UTC)

(outdent) As there have been no objections, I have removed the non-fiction. I have also added a note to the series record. -- JLaTondre (talk) 03:23, 19 January 2017 (UTC)

Thanks... sorry to make extra work for you. After I finish adding the contents to this year's Clarkesworld, I will put in the remaining short fiction. --Vasha 03:46, 19 January 2017 (UTC)

2017-01-16 downtime - 6:30pm

A big patch will be installed at 6:30pm server (US Eastern) time. The server will be down for a few minutes. Patch notes to follow. Ahasuerus 23:12, 16 January 2017 (UTC)

The patch has been installed and the server is back up. As per FR 163, the "storylen" field has been split into 4 fields:
  • a "Story length" field proper
  • a "Content" field for omnibus designations like "1-4". Please note that you no longer need to enter "/" as the first character.
  • a check-box for "juvenile"
  • a check-box for "novelization"
The "New publication" page has been adjusted to support entering these values directly, without having to wait for submission approval. There are new cleanup reports for parent/variant mismatches associated with the new fields. Lots of other data entry forms - "Make Variant", "Add Variant", "Merge Titles", "Unmerge Titles", etc -- have been adjusted. The "juvenile"/"novelization"/Content data has been moved from the old "story length" field to the new fields.
If you see anything unusual, please report your findings here. I will update Help shortly. Ahasuerus 23:43, 16 January 2017 (UTC)
Hurrah! thanks for this. --Vasha 23:44, 16 January 2017 (UTC)
BTW, I would like non-genre to be at the top of the list; I use it much more often than the others. I don't care about the order of the others. --Vasha 23:50, 16 January 2017 (UTC)
Sure, that's easy to do. Unless there are objections in the next 24-48 hours, I will make the change on Wednesday. Ahasuerus 00:05, 17 January 2017 (UTC)
Done. Ahasuerus 20:41, 18 January 2017 (UTC)

(unindent) AddVariant is missing the checkboxes. Will it inhetrit all the new values from the mother work (juvenile/novelization)? Annie 20:33, 18 January 2017 (UTC

That's right. When you create a new title record using Add Variant or Make Variant, the new record inherits the original record's juvenile/non-genre/graphic/novelization/content values. Ahasuerus 20:40, 18 January 2017 (UTC)

Further "story length" changes

The "Story Length" field is now a drop-down list in all data entry forms. Moderator review pages still refer to its values as "ss", "nv", and "nt", but I expect to change everything to "short story", "novella" and "novelette" in the near future.

The name of the field has been changed to "Length" to make it consistent with the way it appears in Edit Publication. More streamlining of various Web pages to follow. Ahasuerus 18:03, 17 January 2017 (UTC)

Query to other editors; would you like to see the options rearranged in the order ss, nt, nv (I would) or are you too used to the existing order? --Vasha 18:43, 17 January 2017 (UTC)
novelette is the least common format (at least with the things I seem to read) so I would rather have it at the bottom. But I can live with them reordered Annie 18:48, 17 January 2017 (UTC)
I have been entering dozens and dozens of anthologies and magazine issues lately; I'd say they are 95 percent short stories, 5 percent novelettes, and almost no novellas. Where are you finding so many novellas? --Vasha 19:06, 17 January 2017 (UTC)
Separate chapbooks from a few publishers for the most part (favorite length so I am seeking them out usually). Novellas are hard for anthologies because of their length - so I am not that surprised at your stats. As I said - I can live with it either way. Annie 19:13, 17 January 2017 (UTC)

(unindent) As of Saturday morning:

| count    | storylen       |
|    39561 | nt             |
|    19226 | nv             |
|   181918 | ss             |

19:30, 17 January 2017 (UTC)

The latest batch of "story length" changes was installed a few minutes ago. It rearranged the "Add Variant" page to look the way Edit Title looks. It also changed all occurrences of "Story Length" and "Storylen" to "Length" to make it consistent. Ahasuerus 20:26, 18 January 2017 (UTC)
In reply to Vasha above, I prefer to see the existing order in the drop-down menu (novella, short story, novelette) because with short story in the middle it neatly separates the two similar words, and inclines editors away from unintentional mistakes. Am I alone in always thinking this was a cunning design trick? ;) PeteYoung 20:50, 18 January 2017 (UTC)
Hm, that's a good point. You're probably right. --Vasha 23:09, 18 January 2017 (UTC)
I always have to look up the definitions of novella and novelette, because I can never remember which one is shorter. So I, at least, would strongly prefer that they be listed in length order. Chavey 04:02, 21 January 2017 (UTC)
The longer the name, the shorter the story  :) I used to mess up novel and novella when I was still learning English. So had to find a way to differentiate the two and the length of the word helped. Then I learned that there is a novellete as well - and the rule for the lengths saved the day. Annie 05:06, 21 January 2017 (UTC)

2017-01-17 server outage - 4:45pm

The server will be briefly unavailable around 4:45pm server time. It should be back up within a minute or two. Ahasuerus 21:32, 17 January 2017 (UTC)

Sorry, that was supposed to be "4:45pm server time". Ahasuerus 21:40, 17 January 2017 (UTC)
The server is back up. A couple of cleanup reports have been adjusted to work with the new "story length" logic. Some very old titles with messed up story length values have been corrected. Ahasuerus 21:47, 17 January 2017 (UTC)

German editor with some time?

The PV is not active anymore so cannot ask him... And I cannot find the German content online. So can someone find the German titles of Im höchsten Grade phantastisch? Thanks! Annie 19:09, 18 January 2017 (UTC)

Removal of non-genre and graphic check-boxes for REVIEWs and INTERVIEWs

The "non-genre" and "graphic format" check-boxes are no longer displayed when editing REVIEWs/INTERVIEWs. Ahasuerus 18:56, 19 January 2017 (UTC)

Coming patch and pending submissions

I have a fairly big software patch almost ready to go. It will wrap up most of the outstanding issues with the "story length" field, including finally changing "shortstory" to "short story". I plan to install it on Monday at 9pm server time. Unfortunately, the patch will invalidate any pending submissions which affect "story length" values; they will need to be rejected. Please plan accordingly. Ahasuerus 00:01, 22 January 2017 (UTC)

Personal tools