ISFDB:Community Portal

From ISFDB

Jump to: navigation, search


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



Archive Quick Links
Archives of old discussions from the Community Portal.


1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · 10 · 11 · 12 · 13 · 14 · 15 · 16 · 17 · 18 · 19 · 20 · 21 · 22 · 23 · 24 · 25 · 26 · 27 · 28 · 29 · 30 · 31 · 32 · 33 · 34 · 35 · 36 · 37 · 38 · 39 · 40 · 41 · 42 · 43



Contents

Roadmap 2017

As of late, I have been tweaking the software based on user feedback and in support of various cleanup projects. It was a good match while I was recovering from the most recent unpleasantness over the last couple of months.

Going forward I hope to get back into more heavy-duty development work. With that in mind I have compiled a list of software projects that are currently close to the top of my list of priorities for 2017. I'd like to post them and solicit feedback re: their desirability and relative priority. If a description seems too vague or incomplete, please don't hesitate to ask for a clarification. Detailed suggestions/feedback re: individual FRs may need to be spun off as separate Community Portal sections. Additional requests welcome!

Continuation and further development of currently active projects

  • Language cleanup:
    • Assign languages to all titles
    • Assign languages to all authors. Should we use the manual approach that we used with titles? Or can we automate some parts of the process based on the language of each author’s titles?
      I think that for the ones remaining (with 3 titles or less), we can just assign automatic English if all the titles they have are English (after all titles have languages). We will miss a few that are not English but we will also miss a lot of them if we go manually - they will require a lot of research at this point. If a non-English title ever appears, we can always change it. That won't be much different to what will happen now if someone adds a magazine in English and do not change the author language manually after the addition... Annie 20:38, 19 February 2017 (UTC)
      Or if someone is too worried about doing it, going the manual way will always work of course. Annie 05:38, 21 February 2017 (UTC)
      I guess the "low-hanging fruit" would be identifying language-challenged pseudonyms of language-enabled authors and auto-assigning the parent author's language to the pseudonym. Ahasuerus 16:07, 21 February 2017 (UTC)
    • Yes, I think we even talked somewhere about that. If those can be done, this will eliminate a pretty good chunk of what is remaining... Annie 16:25, 21 February 2017 (UTC)
  • Wiki cleanup
    • Move series/magazine-, publisher- and publication-specific etc Wiki pages to the database
    • Move Bio and Bibliographic data to the database
Globally OK.Hauck 20:00, 19 February 2017 (UTC)
Along with this (though it might not qualify as part of your currently active projects), I would like to add, it would be very good to try and untangle the main DB from the wiki DB (particularly with respect to login credentials and sessions, etc.; I have a few ideas on this). This would facilitate upgrading our MediaWiki software which we are sorely behind on (including many security/bug fixes as well as features). Uzume 20:41, 19 February 2017 (UTC)
Unfortunately, my knowledge of the MediaWiki software is very limited. Last we talked about development, Al was going to look into this issue, but he has been unavailable for a long time. I could try and get myself up to speed, but, unfortunately, learning new things gets harder as you get older. Ahasuerus 16:18, 20 February 2017 (UTC)
It is already untangled in terms of sessions - I get asked to login in wiki while my session is fine on the site and vice versa. So it is just the users that are the same. Annie 05:38, 21 February 2017 (UTC)

New projects

  • Create a separate queue for automated submissions, which will enable non-moderators to work on them (and let me concentrate on development). Rather time-consuming to implement. Discission moved here.
  • Internationalization:
    • Support multiple prices per publication.
    • Support multiple publishers per publication. May require more thought re: imprints.
      I wonder if that cannot be solved in a different way - allow books published from a joint venture to show on 3 publisher pages - a combined one and the two separate publishers ones. Or if we go for multiple publisher, we should have a way to see which books are from both publishers at the same time without the need to compare lists manually Annie 20:52, 19 February 2017 (UTC)
      An interesting point. I have never considered it, but the proposed behavior seems desirable. We'll have to think of the best way to implement it. Ahasuerus 02:18, 20 February 2017 (UTC)
      And here comes a live example that I and KarenHunt had been investigating: Братья по оружию. It is a joint venture between the Moscow based Астрель and the Minsk based Харвест with separate ISBNs for both (9785271439186 for Астрель and 9789851815919 for Харвест) and usually all copies of the books carry both publishers and both ISBNs (I've had a few similar ones). If you create a fictitious "Астрель / Харвест" (incorrect it is not an imprint) or "Астрель & Харвест", it will remove the book from the two individual publishers' pages. Adding two separate copies (one per ISBN) is not exactly correct either as it is the same book (ha - this is one of the other projects below - multiple ISBNs). The cleanest seem to be to go for one of them and note the other in the notes. None of those scenarios are very good though. Annie 01:09, 25 February 2017 (UTC)
      And just to illustrate why it is a bad idea to use the double name, this wonderful example of Russian thought has 4 valid ISBNs on the same publication - it is again a joint venture between Харвест and this time another of the publishing group АСТ's imprints/daughter companies - this time Хранитель instead of Астрель. But just to make it funnier, it also got ISBN for the parent as well and an ISBN for the pure Moscow "АСТ Москва" which was consolidating their list. So we will need yet another joint version for this one. As you can imagine, there are more of those. :) Annie 01:25, 25 February 2017 (UTC)
      We had a discussion of Russian publishers a while back, which is what pushed this FR up the list of priorities. There are other publishers who use multiple ISBNs, but Russian language publishers account for the majority of our "problem cases". Ahasuerus 01:34, 25 February 2017 (UTC)
      Well - I saw an example, decided to post it so it is in the thread. Sorry if it was repeating already known data - I do not remember stumbling on this discussion when I was reading archives. Annie 01:52, 25 February 2017 (UTC)
      Not a problem at all! I was just sharing additional background information. Part of my job description :-) Ahasuerus 02:03, 25 February 2017 (UTC)
    • ISBNs (mostly to support internationalization, but will also help in other cases):
      • Support multiple ISBNs per publication
      • Move catalog IDs to a separate field, which will help with pubs that have both an ISBN and a catalog ID, e.g. book club publications.
      • Add two checkboxes next to each ISBN: “derived” and “corrected”. The latter will let us capture two versions of invalid ISBNs, the stated one and the corrected one. Discussion moved here.
    • Add support for translators (as well as other roles like single-author collection editors?) Discussion moved here.
    • Move “Add Authors/Transliterated Titles/etc” buttons to the right to free up screen real estate. This will become more important with the addition of new multiply occurring fields (see immediately above.)
    • Change “Family Name” to “Directory Entry”. If we allow multiple values to support different alphabets/scripts, how will we sort by this field? Discussion moved here.
    • Separate translations from VTs on the Title page. Allow users to limit the list of publications to the ones associated with the canonical title.
      Won't that also allow us to group same language translations? If not, then can we have that as well? I would love to be able to see that there are 30 different language translations without seeing that there are 10 French ones until I really want this information :) Annie 20:52, 19 February 2017 (UTC)
      I don't recall this functionality mentioned in the past. I would suggest creating a separate section to explain what you would like to see and to gauge other editors' reaction. Ahasuerus 16:23, 20 February 2017 (UTC)
      I'd like to see this one. -- JLaTondre (talk) 01:22, 20 February 2017 (UTC)
  • Re-do verifications. This will let us have more than 5 primary verifications as well as multiple transient verifications per publication.
    I'd also like to see this one. -- JLaTondre (talk) 01:22, 20 February 2017 (UTC)
  • Create a history of changes to primary-verified publications by storing a snapshot of the way each verified pub looked like right before it was changed.
  • Support for third party IDs (OCLC, BLIC, LCCN, BNF, ASIN, Goodreads, etc). This will enable Fixer to submit ebooks without ISBNs, an increasingly common scenario. Discussion moved here.
  • Make the Quick Tags list user-definable.
  • Add support for additional title types like PLAY and FICTITIOUS ESSAY (requires discussion to come up with additional values.) Discussion moved here.
  • Cleanup reports:
    • Make additional cleanup reports available to non-moderators
    • Review old/incomplete FRs for cleanup reports, add missing title types
  • Add a “non-genre” field to author records; create a cleanup report to find non-genre titles by non-genre authors. Discussion moved here.
  • Add a disambiguator field to title records (requires discussion)
    Don't understand. Hauck 20:08, 19 February 2017 (UTC)
    Is that for the ability to add the reason for the variant (change in name, change in author, translation, abridgement)? If so, I'd love this one. If not - What are talking about? Annie 20:52, 19 February 2017 (UTC)
    The problem that we are trying to address here is that some authors have identically named titles. For example, H. P. Lovecraft's Summary page shows three "The Lurking Fear and Other Stories" collections published in 1947, 1964 and 1971. They are all different, but you can't tell until you drill down to the title level and check each title's Note field. Similarly, there are 2 version of the story "The Rats in the Walls" (1924 and 1956), 4 "[To Albert A. Sandusky]" poems and 9 (sic!) poems whose title is currently entered as "[To ?]". Analogously, Clark Ashton Smith wrote 4 different "Ennui" poems, 2 different "A Sunset" poems, 3 "sonnet" poems, etc. A "disambiguator" field would be used to capture a brief summary of what's unique about each title, e.g. "1964 version", or perhaps the first line if it's a poem. It would be displayed on the author's Summary page. In addition, we will need to decide whether to use this field to capture other information like "abridged", "revised" or "greatly expanded". There were different suggestions the last time we talked about it. Ahasuerus 16:53, 20 February 2017 (UTC)

Ahasuerus 19:50, 19 February 2017 (UTC)

Additional Proposed Projects

  • Add a "printing rank" field to order multi-reprinted titles without pub dates.Hauck 19:57, 19 February 2017 (UTC)
    Yes, please! And not only for dateless - even if we know the dates, a field for edition and printing will be awesome (so if I have 2nd edition, 3rd printing, I can look for 2.3 or something like that and find it without looking through 200 publications). Annie 20:52, 19 February 2017 (UTC)
    There is a Feature request to "Add a 'printing' field to publication records". It would be relatively easy to implement, but we need to decide what kind of data we want to capture. Unfortunately, "editions" and even "printings" do not always follow the standard numbering scheme, so "2.3" won't work. For example, this 1989 edition of Heinlein's "Have Space Suit—Will Travel" says "First Ballantine Books Edition: December 1977 Thirteenth Printing: October 1989". On the other hand, this 2005 edition simply says "First Pocket Books trade paperback edition [no printing number]". This is very common, so you can't expect "editions" to be sequentially numbered. We could limit this field to numeric printing numbers, but there can be any number of "first printings" from different publishers. It doesn't mean that we won't want to implement this field, but we need to understand its limitations. Ahasuerus 04:07, 20 February 2017 (UTC)
    The 2.3 was mostly an oversimplification for the multiple printing scenarios - not necessary requesting it to be numbers only. But we do need some guidelines for formatting in that field - or we will end up with unsearchable field. It will still be better than the current way to find where we are. Even if it is just printing in the field - the edition is kinda clear from the ISBN unless if it gets reused. Annie 04:13, 20 February 2017 (UTC)
    What!? I cannot put Chinese characters in the printing field? But I know of some publishers that mark their printing this way (OK, I am facetiously joking but it is true). Uzume 04:58, 20 February 2017 (UTC)
  • Add a new title type for excerpts, and one for plays/scripts. Neither of those fit nicely in SHORTFICTION. --Vasha 21:02, 19 February 2017 (UTC)
  • Another useful feature, mainly for links from external site to the ISFDB: stable IDs. Currently, if a title is merged into another its ID ceases to exist in the database. As a result, links from external sites to such a title record will become broken links. The software should instead keep track of merged IDs and redirect to the new ID (there was a discussion about this some time ago but I just couldn't find it). Jens Hitspacebar 21:10, 19 February 2017 (UTC)
  • [Discussion of third party IDs moved here.]
    1. The next item I would like to see is revamping verifications. I am not sure how valuable it is but it has plagued us for a while now. Uzume 21:36, 19 February 2017 (UTC)
    2. Finally, author and publisher directory updates seems like a good item. This could bed sooner but probably will be easier after more internationalization/localization is completed so doing it a bit later might prove less problematic. Uzume 21:36, 19 February 2017 (UTC)
  • There had been some discussion about reviews of magazines here. I think the discussion petered out rather than concluded, but did get into alternate ways of dealing with magazine series. I'm not pushing for it, just reminding. Doug H 21:59, 19 February 2017 (UTC)

Editor review of submissions: "automated" submissions sidebar

Create a separate queue for automated submissions, which will enable non-moderators to work on them (and let me concentrate on development). Rather time-consuming to implement. Ahasuerus 00:10, 20 February 2017 (UTC)

Yes, please :) I know that it is a time consuming change and so on but it should help in the long run... Annie 20:52, 19 February 2017 (UTC)
I am for editor review of submissions (by Fixer, etc.), however I question the need for a separate queue. Uzume 23:02, 19 February 2017 (UTC)

(unindent)I have some reservations about "automated submissions" (but that maybe based on my lack of understanding) referred to above in #Roadmap 2017. Why do we need another submission type like this? It seems to me this FR is just to allow editor reviews of submissions (like a voting system to help moderators close pre-reviewed submissions). Is there some reason some submissions should not allow editor review? Uzume 21:45, 19 February 2017 (UTC)

Because at the moment Ahasuerus is doing all of them. This is the process by which all newly published books are added to the system - so we do not wait for people that have them to add them. The idea is to allow the queues that the automated robot finds to be worked on by other people as well - which includes verifying that it is indeed eligible, cleaning the record based on our standard and so on. It is not about approval of entries from people, it is about adding the entries in the DB so the moderators can approve them. Annie 21:50, 19 February 2017 (UTC)
I do not see a difference with this. It is true bot generated submissions maybe of lower quality but then so are submissions from new users. I do not think we need a new field specifying the origin of the submission. I like the editor review of submissions concept (perhaps with comments and queued results to be approved by moderators). In the general sense, consistent high volume and high quality editor reviews of submissions could be a very good way of selecting prospective new moderators. Uzume 21:55, 19 February 2017 (UTC)
We do not have real bot submissions now - Fixer is manually operated by Ahasuerus, title by title, every month. That idea is to allow these queues to be processed by other people as well. Annie 22:03, 19 February 2017 (UTC)
I understand he is doing significant manual work on his side of bot before making submissions and to lighten his load, we want to be able to have his bot make lower quality submissions with better review from our community (instead of just him) and I agree with and would not argue on that point. However, it seems to me a generalized editor submission review process is a better solution than a one targeted just at this problem (which adds unneeded extra levels and fields for such). Uzume 22:10, 19 February 2017 (UTC)
And how is that different from making more people moderators if there are people that can do reviews like that? :) Plus - the process of accepting edits is already slow, do you really want to add more layers? A new editor will get discouraged fast. Plus - that won't solve the issue with Fixer and the sumissions - no matter who reviews, they need to get into the system one way or another. If you want all that it finds to be just added and someone reject it if it is not genre and/or not eligible, that would add a lot more work on the moderators... A Fixer, non-massaged entry is missing series information, have (or can have) a weird spelling on author and publisher, title (Amazon adds a lot of junk there) and it may need to be merged somewhere. No matter how many layers of whatever we have, if those just get dumped into the regular queues, the real updates will get delayed with days until the pure deluge of those is dealt with. Annie 22:18, 19 February 2017 (UTC)
I never suggested making editor review mandatory—just generalized. I do not understand why the normal queues would cause delay. Submissions are not required to be moderated in any particular order (I understand there are order issue with regard to moderation however). Uzume 22:36, 19 February 2017 (UTC)
No but delaying a new contributor edit while we are dealing with internal ones is a bad idea. And if you have 12000 Fixer submissions in the regular queue, how will a moderator find a new one. And even if they can, working on those ratty ones will be a longer and more involved process than on user-created ones. Thus the separate queues and the ability to do something before they hit the moderators. :) Annie 23:13, 19 February 2017 (UTC)
That sounds to me more like better management of the current queue is needed not another queue. Make the submission queue searchable and a moderator can for example just say "I do not currently want to see submissions by Fixer" (or say any user with a bot flag; this list is not very long Special:Listusers/bot). Uzume 23:40, 19 February 2017 (UTC)
The main difference is allowing editing before submitting - allowing the entry to be cleaned up before it goes into the proper queue for approval. This is not something moderators can do now - they can only accept and then edit after that. If you are saying that moderators should be able to directly edit ANY submission before acceptance, then yes, better management is all that is needed. But I am not sure we really need that. Annie 23:45, 19 February 2017 (UTC)
OK, so you are saying you want a separate queue and allow reviewing editors to edit/transmute the submission as part of the review process? That would be very powerful but also extremely difficult to code (since submissions are actually only semi-structured XML documents). Uzume 00:39, 20 February 2017 (UTC)
Thus the comment above that it will be very complicated :) If you read the FR, this is what it describes. Annie 00:40, 20 February 2017 (UTC)
Maybe Annie means a tiered submission process where editors can review automated submissions converting them to normal submissions or some such. But then in my mind "automated" just means "I want editor review first". Uzume 22:02, 19 February 2017 (UTC)
Not really. The current automated process is; Fixer finds the titles (wonderful), Ahasuerus submits them to the DB (from his name or from Fixer's name). Anything with low priority just stays in the queues until someone gets to them. Or forever. It is not about magazines, it is really about what the robot finds and needs to be processed. And you do not want to add to the moderator load all the "cleanup" that is needed - there is a LOT of work to be done on those submissions. And just dumping them into the DB without cleanup, even with a flag will dilute and make the DB useless fast.Annie 22:09, 19 February 2017 (UTC)
I am not arguing against editor review for Fixer submissions. I am arguing this is more elegantly solved with a generalized process of editor review not specific to Fixer submissions. Uzume 22:13, 19 February 2017 (UTC)
Baby steps. Plus Fixer (and any other robots that can find more entries). It is not Fixer specific really - it is the ability to handle those kinds of submissions in a slightly different way. And I still argue that if a person does the submission, you do not need it to be delayed further. :) Annie 22:20, 19 February 2017 (UTC)
So you are saying the "automated" flag adds another tier delaying such submissions. I do not think that is necessary (and if you read the FR a moderator can directly moderated such without editor review anyway). The point is we do not need the flag can just implement generalized editor review of submissions. Uzume 22:35, 19 February 2017 (UTC)
If someone new does not understand the page, they may click it, sending the submission in a long(er) queue. What we need is a double queue - one that only moderators can deal with (the ones that had been seen by a human and just need the second set of eyes) and one for any "ratty" submission where more people can help with. Which is what this FR is for - allow a new process for submissions. Annie 23:09, 19 February 2017 (UTC)
I am all for editor review of submissions to help with such "ratty" submissions. I do not think we need another queue (chosen at submission time), just better management of the current queue should suffice.

OK, after some discussion...if we are talking about a totally different process where someone or something provides suggested changes (I am intentionally avoiding the word "submission") which are reviewed and potentially generate submissions (a sort of reviewed and potentially modified transmutation from the original suggestion), that is a totally different beast and I am not at all sure it makes sense to leverage the current submission system for this sort of thing. I believe Fixer and other bot like "animals", normally do not make arbitrary submissions but only very specific types (mostly NewPub; someone tell me what other types it can make). As such, it might make much more sense to have separate NewPub (suggestion? submission?) queue. A reviewer could then load such NewPub items into the NewPub editor, potentially make changes, and make the submission (or mark the suggestion rejected). This would greatly simply such an implementation (which would still not be trivial). It might also make sense for bots to mark items in this NewPub queue as completed (or actually delete them) when it noticed the items appear in the main database that match the NewPub suggestion it previously made. For this purpose, there should probably be a way for bots to query this queue (with search requests like "give me all outstanding NewPub items I provided but I have not marked as completed/deleted"). Frankly, I see this as more of a remote bot NewPub queue than an automated submission queue. Uzume 01:24, 20 February 2017 (UTC)

AddPub as well when it manages to recognize where a new publication belong. Fixer founds a few thousand new ISBNs every month. They need to be added to our DB - but they do need a lot of cleanup. What is your proposal - how those say 6 0000 publications get added without the new process and without burning out all the moderators? If Fixer can just dump them in a new queue where someone can go, edit and then submit to the moderators, this is exactly what the FR is proposing - call it automated submission queue, call it "list of possible NewPub/AddPub", call it whatever you want :) So do you just disagree with the name? What you describe here is exactly what the FR is proposing... It is not about changing the current process, it is about adding a new process BEFORE the current one that will allow these ratty ones to be streamlined for the process. Annie 01:39, 20 February 2017 (UTC)
That is not how the FR is written "Change the submission table to support a new submission state, “A”utomated" implies modification of the current submission queue. I do not think that is appropriate if what is really needed is a remote bot queue with limited input types. Uzume 02:11, 20 February 2017 (UTC)
Look at point 10 in the FR - that is what ties it back into the standard process. Annie 02:13, 20 February 2017 (UTC)
I see that now, however, I still think that unduly complicates the submission system with little value. I believe we would be better off with a new different specialized queue than trying to shoehorn this functionality into the current submission queue. Uzume 02:20, 20 February 2017 (UTC)
The linked FR would effectively create a new specialized queue. Editors would then use "automated"/robotic entries in that queue to create regular submissions. Implementing various supporting mechanisms -- like putting the automated submission on hold as described in the FR -- would be somewhat challenging, but I think it should be doable. Ahasuerus 04:58, 20 February 2017 (UTC)
I imagine it would be challenging both on the API server side of things as well on the bot client side of that (what does/should Fixer do with such a remote queue item marked on hold?). Uzume 05:23, 20 February 2017 (UTC)
When Fixer sends a submission via the Web API, he marks the ISBN as "submitted" in his internal database. From that point on he ignores the ISBN.
When Fixer gets the next weekly backup, he updates his internal database with the data from the backup. At that point the status of moderator-approved ISBNs changes from "submitted" to "already in the ISFDB". Moderator-rejected ISBNs remain "submitted" forever. It doesn't really make a difference because Fixer ignores "already on file" ISBNs just like he ignores "submitted" ISBNs. Adding a new queue on the server side shouldn't change this logic on the client side. Ahasuerus 15:16, 20 February 2017 (UTC)

(unindent) If there's a separate queue, that queue will probably back up (esp. once the novelty wears off). If it does back up, we'll end up in a situation where more of its entries turn out to be duplicated by live-editor submissions that were created without consulting that queue. It might be better to get more moderators and let Fixer submissions flow through without any sort of pre-qualification/filtering that's being done now. We are not particularly aggressive about recruiting moderators. --MartyD 12:03, 20 February 2017 (UTC)

Unfortunately, the main problem is not that we don't have enough moderators. The main problem is that processing robotic submissions requires a significant amount of research and TLC. Some moderators have the time and the energy to do the necessary research. Others don't and simply click the "Approve" button if the submission looks OK. This is the main reason why I only submit on Fixer's behalf if:
  • I am 99% sure that the submission (usually an AddPub) is truly OK "as is", or
  • it's a relatively low priority ISBN and it's better to have it on file in a potentially suboptimal state than not to have it at all
Over the years, I have tried a number of strategies to improve the situation, all of them unsuccessful.
The "automated submissions queue" is the latest stratagem in a long list. The idea is that having human editors do the requisite research up front would result in higher quality submissions to be reviewed by moderators. Admittedly, if a moderator wants to pull up the new queue and simply approve everything in it, it won't stop it.
If there is a better solution to this problem, I'd love to hear it. The current situation is barely sustainable as it is and will continue to deteriorate as my productivity declines over time. (Not to mention the increased number of SF books being published.) Ahasuerus 19:15, 20 February 2017 (UTC)
That makes more sense and I prefer that idea. This is why I am sort of against the idea of another queue (particularly if it is shoehorned in the the existing one as the first part of the current FR describes) despite its possible value in being able to modify the entries at review time (it seems like much work where this is the only key value). That said, it might make sense to add generalized editor review for the main submission queue (it could be limited in some way if there are security concerns). Such reviews could help moderators more quickly decide when closing submissions. As Marty points out such things may turn into a novelty (but then same could be said of moderators; look at how many inactive or barely active ones we have at the moment), but it might ebb and flow with new or return editors, etc. Aside from the possible value of possible valuable reviews to speed in moderation, it seems like a better tool to use when hunting for moderator candidates (so though this too might be complex and end up perhaps with smaller value this part seems to me the most valuable part). Uzume 18:24, 20 February 2017 (UTC)
If we go this way, we really should have a prioritization of some type available so that live editor updates do not get backed up when Fixer dumps its submissions. It is very annoying to wait for a moderator to approve something so you can send the next update (especially when you are new) :) Annie 05:32, 21 February 2017 (UTC)

Adding support for translators and possibly other roles

Add support for translators (as well as other roles like single-author collection editors?) Ahasuerus 23:45, 19 February 2017 (UTC)

Ok for the former, no to the latter, why not editor of novels? Hauck 20:08, 19 February 2017 (UTC)
A collection editor usually chose the stories, a novel editor does not chose content in the same way. I think we should allow such editors be somehow recognized. Annie 20:52, 19 February 2017 (UTC)
I am with Hervé here. I would like to added more contribution types supported when we have no way to capture such now but I would be wary of taking what we already have and dividing it down (into different types of authors/editors or different types of artists, etc.). I definitely want to see translators (since our current rules have no fields to capture this short of ad hoc notes). I am curious why we cannot just add translators as authors of translation title records and just reach through the VT to find the original authors instead of adding a new contributor type (we do not need one for artists they just tend to have different types of works; a different language VT work is a different type of work). If we implement such, we could have a cleanup report for translations where the canonical authors (jumping through pseudonyms) match authors of the original work allowing us to convert these over time (translations without translators report). Uzume 23:20, 19 February 2017 (UTC)
So you are proposing the Bulgarian variant of Dune to have as an author the translator? How would you separate on the translator page the ones he did write from the ones he translated? And if a user does not understand out variant system, they can misunderstand who the writer is. Plus this way we are losing the ability to have the actual author name in the language of the variant... Artists are different because they are different works - the translation by definition has two authors - the original one and the translator. Annie 23:24, 19 February 2017 (UTC)
The software can display these differently by reaching through the translation variant and author psuedonyms to properly credit authors vs. translators. Uzume 23:33, 19 February 2017 (UTC)
How about an example. Dune by Frank Herbert is translated as Дюн by Франк Хърбърт, translated by Виолета Чушкова. Which name goes where in your idea? Annie 23:37, 19 February 2017 (UTC)
I am assuming we are referring to T1442269. I am suggesting we just add Виолета Чушкова to this record as an author and the software just credits the translators differently than the authors by chasing the authors of this record from A237335 to A30 (since A237335 is a pseudonym) and whatever number Виолета Чушкова ends up (since that is not currently in the DB) and comparing that to the authors from T2036 (which is the variant translation parent of T1442269) which is A30. The software can clearly detect that A30 is the original author and whatever number Виолета Чушкова ends up is not (and thus is a translator). In a similar vein, cleanup reports could be generated for translations without translators. It should be noted that all of the above data is already required to display and properly link these entries anyway. This proposal just suggests handling that data differently to allow for and credit translators (there is already an FR900 for displaying translations differently; I just want to add translator credit support to that and propagating it to more than just title pages). Uzume 00:10, 20 February 2017 (UTC)
None of your links work by the way - you may want to look at the templates again:) The example was from my library. I get where you are getting with that. But... what about the case where it is not just a translation but also an abridgement. This is when the second author gets added now. And that will make the translator author page a nightmare for the software to work out - in which cases the author is a translator, in which cases he/she is a co-author, in which case an author. Not to mention that the searches for translators will become overly complicated. Annie 00:14, 20 February 2017 (UTC)
Currently our rules rule out using the VT mechanism for any derived (where the contents is significantly different) works except translations so that should not be an issue. In partially translated works and the like there should be no VT parent and whether an author is an translator or not becomes muddled to begin with. I believe it would be best to list all contributors as authors and specify who did what in the notes (much as is done with certain types of authorship now). Uzume 00:26, 20 February 2017 (UTC)
Not true. Abridgements are variants - in a way a lot of translations are abridgements, especially the older ones. As are two parts of a split novel. Revised novels also get varianted... Annie 00:42, 20 February 2017 (UTC)
We did not used to allow VT title records except to change the title or author and then later allowed translations (i.e., changes in the language). If indeed we now allow other derived type VT title records, I would prefer a translation flag marking a VT title record as a translation over adding new contributor role flags (add a field to title records instead of to author records). The problem with using the VT mechanism for generalized derivatives is: what constitutes a derivative? Is something a derivative if it is barely inspired by something else? As you can see this gets rather sticky quickly and the resulting connections are more then the VT system can support (since that would actually require a generalized graph construct). Uzume 01:38, 20 February 2017 (UTC)
We are already using them for that (as much as I dislike it in some cases - split novels for example) - the question is how to make it a bit more manageable. And as for the flags - if a variant is an abridgement AND a translation from different people, how do we determine who is who? We can use additional authors but we will need a flag on the author as well... Annie 01:52, 20 February 2017 (UTC)
You cannot use VT to specify abridgement AND a translation by different people anyway. That would require more than a two title records to express (one would have to link the translation to the abridgement and the abridgement to the original; our VT mechanism specifically does not allow generalized graph structures). Uzume 02:08, 20 February 2017 (UTC)
You cannot have a variant of a variant - so if my Bulgarian book is an abridgement and a translation, it goes under the main work directly. You need one title to express - you just need to add notes. Annie 03:21, 20 February 2017 (UTC)
Exactly, and in the same notes that qualify such you can qualify the contributors as well. If you cannot have the titles linked perfectly (outside of notes) it makes little sense to try and credit people perfectly. Just as you have to pick the parent (even if it is not right) you can pick if it is a derived work or a translation (even if neither of those is entirely right either). If we ever support such a linking then the credits will be able to be right too. I see little reason to hack around credits to solve the real problem. Uzume 04:12, 20 February 2017 (UTC)
And here we ended up on a circle. I cannot see how your idea is easier than a new role (considering all the additional work that will be needed to populate summary pages. And if it is not separate, something will need to be done on the publication and title pages to identify them as translators/whatever they are anyway because new contributors will be confused. Annie 04:20, 20 February 2017 (UTC)
Easier solutions do not always make for better solutions (in fact the easy way often ends up being hard long term). I am not sure how new contributors would be any more confused than by which is the proper variant parent (which cannot be set properly too). Uzume 04:54, 20 February 2017 (UTC)

(unindent) The issue of translator support has been open for close to 5 years now, so I don't expect us to come up with a perfect solution in a few hours. There are various aspects to consider, e.g. the fact that there are awards given to translations rather than to titles.

The reason that I mentioned "roles" is that whatever design we come up with will ideally also support other "roles" like single-author collection editors. The exact roles that we will eventually choose to support are less important than the decision to make the design extensible -- or not, if we find that translators are sufficiently different from other "roles". Ahasuerus 05:11, 20 February 2017 (UTC)

Yes, I was not suggesting the translators issue would be solved anytime soon. I am against dividing our author records into roles however, and just wanted to state that there are potential solutions for the translators issue without depending on the introduction of divided contributor role tags. If we do end up supporting such role tags, I would recommend corollaries for publisher roles (or any other authority control item), etc. Uzume 05:16, 20 February 2017 (UTC)
I don't know how useful it is to researchers, but I like the idea of being able to capture/catalogue various roles. Part of the challenge right now is that the nature of the relationship is embedded in one of the two ends (mostly in the publication/title end, but sometimes in the author end). Thinking about the relationship in terms of a generic "contributor", I could see typed Contributor relationships instead -- the nature of the relationship stored on the relationship. There could be many of these, and a pre-defined set of types. One type would be "Author", another "Editor", another "Translator", and so on. The bibliographic summaries for people could be organized by roles, then title types. To keep things simple and avoid big mistakes, the software could provide some specialized handling for required roles (e.g., it could still present Author (for single works, collection, and omnibus) or Editor (for anthology and magazine)) and then "other contributors" or something like that for everything else (just like we get the Title record but then other Contents). --MartyD 17:42, 20 February 2017 (UTC)
I have been thinking along similar lines for a while now. However, redoing the author logic (and the variant title logic and a lot of other things) would be a daunting proposition. It may be less painful to declare authors and anthology/magazine editors a "special privileged case" and implement a generalized "contributor/role" mechanism for translators, other types of editors, etc, separately. Once the new mechanism is in place and everything is working smoothly, we can look into migrating "special case" authors/editors to the new system.
Granted, a two-step approach is not without its dangers -- I once worked on a multi-billion dollar project which took this route and never completed the second step -- but we may be better off even if we never complete the second step. Ahasuerus 23:59, 20 February 2017 (UTC)
Well, we need to solve it if we really want to claim that ISFDB is international. I do not want to add 3000 works just to have to edit them in a year to get the translators sorted... Just saying :) And I like Marty's idea. Annie 00:04, 21 February 2017 (UTC)

Non-Genre flag for authors

Add a “non-genre” field to author records; create a cleanup report to find non-genre titles by non-genre authors. Ahasuerus 00:04, 20 February 2017 (UTC)

This will open the gates to well-intentioned persons that will want to enter such authors (as with the "graphic" or "non-genre") as it will look possible. Bonus problem: how to define a non-genre author.Hauck 20:08, 19 February 2017 (UTC)
[Discussion of author birthdays and dates of death displayed on the front page moved here.]
I believe adding a genre field to authors should be fairly easy and provide good value (like moderator warnings on submissions when adding non-genre or graphic content to non-genre authors, etc.). @Hauck: all authors are non-genre by default and those "over the fold" get promoted to "genre" and we allow (nearly) all content for them. Uzume 21:36, 19 February 2017 (UTC)
Sure, and promoted by who? We're back to the remarkably precise definition of "over-the-threshold" (or "over-the-fold"). This may sound funny but trying to explain for the upteenth time to another new contributor all these perfectly nebular notions may prove an interesting expreience for those who do not practice it. Hauck 21:55, 19 February 2017 (UTC)
Promotion (and demotion) is via the moderated submission process (changing the author genre/non-genre checkbox). It could be restricted to moderators too (like author canonical renaming, etc.) though I am not sure that is necessary. Education is always useful and we already have the rule. The only difference is having a field to declare such. Uzume 22:58, 19 February 2017 (UTC)
I really do not like the idea. I do not think that we should have non-genre works even by the over the threshold authors but that ship had sailed. And how we will determine who is genre author? If someone has a story/essay here, they are an author with genre works. Anyone that has at least one non-genre work is again an author with genre works. Trying to draw the line in the middle is going to cause a lot of unnecessary edits.
I can think of a few Bulgarian authors that had written both SF and Crime works and are considered masters of both. I would not add their crime works here or call them non-genre because they just happen to also had written outside the genre. Even the ones that under the usual "rules" will be over the threshold. Annie 00:10, 20 February 2017 (UTC)
This is already specified in our Rules of Acquisition. I agree some cases are not clear cut. If you want to challenge the rule (or champion a specific author for promotion or demotion) that is a different discussion than implementing it in software. Uzume 00:20, 20 February 2017 (UTC)
It does not determine what a non-genre author is. Again - where would you like to draw the line? If you want it to be based on what an editor wants to nominate, it becomes meaningless... Annie 02:14, 20 February 2017 (UTC)
What you are saying is the current Rules of Acquisition are meaningless in this regard (and I agree that could be argued) but that is a different (though valuable) discussion. Uzume 02:38, 20 February 2017 (UTC)
No, what I am saying is that the rules determine which works are added but do not qualify authors as genre or non-genre ones (above the threshold is not a determination of that).Annie 02:52, 20 February 2017 (UTC)
This seems a pointless designation. If an author has written a genre story, they are by definition a genre author. If it is attempt to designate authors who write primarily genre stories, what is the point? If it is an attempt to designate authors who are 'above the threshold', that is not the same as authors who primarily write genre stories so the name is deceiving. And as Hauk has pointed out 'above the threshold' is a nebulous thing that is not well suited to a database field. -- JLaTondre (talk) 01:15, 20 February 2017 (UTC)
I am curious why you think this is not suited to a database field? I agree an author could be promoted or demoted to threshold levels over time (an author starts out in one genre and gravitates to another). Should instead every editor and moderator know and potentially reevaluate each author upon every submission? That would make for very complex submission criteria and potentially break the rules of acquisition as different people came to different conclusions at each point in time. Uzume 01:58, 20 February 2017 (UTC)
Everyone has a different opinion of 'above the threshold'. People already come to different conclusions. A database field is not going to change that nor is it going to change that different editors and moderators apply it differently. It would just be a field they can now edit war over. -- JLaTondre (talk) 02:17, 20 February 2017 (UTC)
Edit warring over that single field is considerably more noticeable than generalized edit warring over all the pubs and titles of an author which what we are already at. If there is an edit war over that field it will be noticed and brought to community discussion more easily and thereby a consensus can be reached. I agree we could also likely generate some sort of automated heuristic to flag if an author should be above the threshold (by counting title and/or pub records) but it would not take into account exceptions by consensus. But the proposed flag is meant to hold the current value of community consensus (which obviously can change). Uzume 02:32, 20 February 2017 (UTC)

Derived and corrected ISBNs

Add two checkboxes next to each ISBN: “derived” and “corrected”. The latter will let us capture two versions of invalid ISBNs, the stated one and the corrected one. Ahasuerus 00:12, 20 February 2017 (UTC)

Not frequent enough to clutter the screen, better use the note field instead.Hauck 20:08, 19 February 2017 (UTC)
I agree with Herve on that one. Annie 20:52, 19 February 2017 (UTC)
The proposed check boxes would only appear on Edit/Add/Clone Publication pages. Regular Publication pages would continue to display "(Bad Checksum)" for invalid ISBNs like they do now.
The advantage of having invalid ISBNs captured in the ISBN field vs. in the Notes field is that it enables searches. For example, if you search for the ISBN stated in Alpha 5 (0-345-24140-X), you won't find it because it's only available in Notes at this time. When dealing with invalid ISBNs, we have always had to choose whether to enter the stated version or the corrected version in the ISBN field. The other version was relegated to Notes where it became unsearchable. With the addition of support for multiple ISBNs, we will no longer have to choose -- we will be able to eat our cake and have it too! :-)
As far as derived ISBNs go, there are hundreds, if not thousands, of them in the database, mostly from the mid-1970s when the industry was transitioning from catalog IDs to SBNs and then to ISBNs. It's always made me uneasy that we claim, e.g., that Alpha 4's ISBN is 0-345-23564-9 even though it says "345-23564-9-125" in the book. If we add a check box to the edit page, the main Publication page will be able to indicate that the ISBN value was derived. Ahasuerus 03:15, 20 February 2017 (UTC)
I too agree and believe implementing ISBNs as identifiers (a different FR) will likely solve much of this problem anyway. The key is to differentiate identification (e.g., cover price, etc. which can be erroneous) from identifiers (which probably should not be erroneous). Uzume 00:23, 20 February 2017 (UTC)
I still believe most usages of this can be covered by treating valid ISBNs as identifiers (in the as yet unimplemented identifiers FR) and invalid ISBNs as catalog numbers. Here is some potentially pertinent information on this subject: MARC ISBN. Uzume 03:47, 20 February 2017 (UTC)
Back when I was working on the design of the "third party identifiers" FR, I considered making catalog IDs and ISBNs just another type of identifier. Eventually I decided against it for a number of reasons:
  • Unlike third party identifiers, catalog IDs and ISBNs are stated in publications
  • Also unlike third party identifiers, catalog IDs and ISBNs are displayed on various "Publication Listing" pages
  • ISBN searches are "privileged" in the sense that they are available via the main search box
  • ISBN searches use a special ISBN-10/ISBN-13 conversion algorithm so that a search on an ISBN-10 finds a matching ISBN-13 and vice versa
  • ISBNs can be "derived" or "corrected" as described above
In the end I decided that catalog IDs and especially ISBNs were sufficiently different animals to merit separate places in the database. Ahasuerus 04:17, 20 February 2017 (UTC)
Those are good points, however, an ISBN as an identifier can be converted to a 13 digit number in all cases (and left in original ISBN-10, SBN or other brokenness as stated in the publication in other cases like the catalog number field). When searching ISBN identifiers, ISBN-10s to search for can be converted to 13 digit numbers before comparisons (so there is no issue). It would not be so hard to have a combined search for these and the catalog field(s) (matching original input against catalog fields and any convertible ISBN-13 against the identifier fields). Though very common, all (and sometime any) ISBNs for an edition are not always stated in its printed publications (e.g., I have seen some that only have an GTIN-14 which contains the ISBN-13 and another digit). I am not sure it is worthwhile to implement ISBN as both catalog numbers and identifiers and to accomplish such (but it is something to think about). Another issue is broken punctuation in ISBN. I know sometimes an ISBN is stated in a publication with improperly placed hyphens (I have no idea how we handle this if at all; I am guessing we do not maintain this original statement). Uzume 04:49, 20 February 2017 (UTC)
There is a great deal (2427 lines to be precise) of ISBN formatting logic in this module. It's yet another way in which ISBNs are different from third party identifiers. Ahasuerus 15:20, 20 February 2017 (UTC)

Changing "Family Name" to "Directory Entry"

Change “Family Name” to “Directory Entry”. If we allow multiple values to support different alphabets/scripts, how will we sort by this field? Ahasuerus 02:39, 20 February 2017 (UTC)

Switching to unicode and then sorting by it will be cleanest. Until then I kinda like it as it is (as long at non-Latin entries actually have their transliterations properly and not getting defaulted to the name of the author in English. Annie 20:52, 19 February 2017 (UTC)
I have been looking forward to the DB moving to some Unicode encoding like UTF-8 for a long time (currently it is only pseudo-Unicode by way of using HTML entities). Multiple directory entries solves more than just multiple script/language issues (see ISFDB:Community Portal/Archive/Archive41#Sorting, author directory and nobiliary particles). Multiple scripts can be handled by multiple directories. Uzume 00:51, 20 February 2017 (UTC)
Multiple scripts/multiple directories becomes a bit of an issue with author names with letters from two separate scripts - Macedonian or Ukrainian names for example which combine Cyrillic (somewhat creative on some letters) and Latin letters. Which directory will have these forms? Or do we start a separate directory for each of them? Annie 02:44, 20 February 2017 (UTC)
This is not necessarily their real name anyway. I would suggest making entries for both (all Cyrillic and all Latin even if their real name is a mixture of the two). Uzume 03:03, 20 February 2017 (UTC)
For Ukrainian and Macedonian authors, it IS their real name. And we all hope we will get more international entries, right? Saying that they do not deserve their real names in a directory while we have everyone else's name there will be a bit... uninclusive. Annie 03:19, 20 February 2017 (UTC)
I do not see how that is an issue. The above mentioned "nobiliary particles" discussion proposed having multiple entries based on different cultural conventions in different places. Uzume 03:29, 20 February 2017 (UTC)
So separate directory for each language we support (I am just trying to make sure I understand the idea) Annie 03:37, 20 February 2017 (UTC)
No, not for every language. One per script (all Latin in one, all Cyrillic in another, etc.) implemented as time and demand allows. This means for example English language authors would be found in the same directory as German ones. Another example of directory entries that do not match real names would be Japanese (which would have kana entries) where I do not think we want to consider a kanji Chinese character directory (I have no clue how we would do such for actual Chinese names). Uzume 03:53, 20 February 2017 (UTC)

(unindent) Let's take a step back and examine the uses (current and proposed) of the "Family Name" (soon to become "Directory Name") field. At this time it is used to do 2 things:

Making this field a "multiply occurring field" will make it possible for an author record to appear on multiple Author Directory pages. For example, if we specify "de la Roche" as well as "Roche" as Mazo de la Roche's Directory Entries, his name will appear on two different Author Directory pages. Once we implement non-Latin Author Directories, it will also enable us to make the same author appear in multiple directories.

So far so good. However, once an author has multiple "Directory Entry" values, we will have no way of using them for sorting purposes. Unless we make one of them our "preferred sorting value", I guess. Ahasuerus 03:49, 20 February 2017 (UTC)

Agreed. And as such instead of having a "preferred" tag, why not treat this like transliterations. You have a Family name with "transliterated" Directory names on top. This would allow a mixed (potentially collating) name as a family name (we could have Cyrillic and Latin or kanji and kana in this field) and single script directory names on top. Uzume 03:57, 20 February 2017 (UTC)
I am not sure I understand what "on top", "mixed name" and "potentially collating name" mean in this context. It sounds like you may be suggesting that we keep the current "Family name" field and add a new multiply occurring field for "Additional Directory Entries". The latter would be used for names like "Roche" in the "Mazo de la Roche" example above as well as transliterations. The former would continue to be used for sorting purposes. Is that about right? Ahasuerus 15:45, 20 February 2017 (UTC)

Add support for additional title types

Add support for additional title types like PLAY and FICTITIOUS ESSAY (requires discussion to come up with additional values) Ahasuerus 02:41, 20 February 2017 (UTC)

Not enough candidates to warrant new types.Hauck 20:08, 19 February 2017 (UTC)
Maybe not for fictitious essays; --Vasha 00:52, 20 February 2017 (UTC)
"Fictitious essays" or "fictional essays" are basically "in-universe" essay. They are written as if the events of the work that they are associated with were true. They have prompted many discussions since it's not clear whether they are "essays" or "short fiction". Help currently says:
  • Some books contain fictional essays, purporting to written by a character in the book, as introductions or afterwords. There is no "FICTIONAL ESSAY" title type, so you have to choose whether the title is better described as SHORTFICTION or ESSAY.
There have been repeated request to implement a separate title type for them. Ahasuerus 02:48, 20 February 2017 (UTC)
Well then, if there have been repeated requests, clearly there are enough cases to justify adding the new type. And I will say it definitely sounds useful to me. --Vasha 03:37, 20 February 2017 (UTC)
but for plays, even if there aren't that many of them, the difference between them and SHORTFICTION is so obvious that they need their own title type. --Vasha 00:52, 20 February 2017 (UTC)
I would also like to see a separate title type for plays, but we will need to decide how to handle related cases first. For example, are movie scripts, TV scripts, etc separate types or are they all the same type? If they are the same, should we come up with a more generic term than "play"? Ahasuerus 02:51, 20 February 2017 (UTC)
"script" covers plays, audioplays, tv scripts, and even librettos I think. --Vasha 03:37, 20 February 2017 (UTC)
(And for the other one I would like to see a new type for, excerpts, there really are a lot.) --Vasha 00:52, 20 February 2017 (UTC)
The vast majority of excerpts are works of short fiction. Should we treat them as a separate title type or as a separate "length" value like novellas, short stories and novelettes? Ahasuerus 02:52, 20 February 2017 (UTC)
I'd like a separate length value for these - this will separate them from the real short fiction. Annie 02:54, 20 February 2017 (UTC)
Keep in mind that if we add "excerpt" as a new "length" value, it won't separate excerpts from other works of short fiction on Summary pages. Ahasuerus 03:18, 20 February 2017 (UTC)
I believe you mean it won't currently separate such (the software could be made to do such without huge issues though I am not convinced that is a good idea). I vote for an "excerpt" "length" value. Uzume 03:21, 20 February 2017 (UTC)
I do not like seeing novel excerpts mixed in with the actual short fiction on the summary pages. --Vasha 03:37, 20 February 2017 (UTC)
It does not do it now anyway (See Asimov - the third and the forth are excerpts... If we go for separation one day, we may start talking about separating all lengths from each other anyway. What I meant upstream was that it will allow the excerpts to be seen easier. And allow searching them - and searching without stumbling at them. Annie 03:40, 20 February 2017 (UTC)
Agreed. Though I am not convinced about separating such on author pages. One can create custom pages via search that show just what you want. Uzume 04:17, 20 February 2017 (UTC)
I would be strongly against separating all lengths on author pages. It's not of interest under most circumstances, plus every author has lots of unspecified lengths. --Vasha 04:21, 20 February 2017 (UTC)
I am not exactly vying for it but it might be interesting to consider user preferences allowing one to select which lengths one wants to see (much as language selection is possible this way). Uzume 04:25, 20 February 2017 (UTC)
I like that, it would speed up searching for titles on prolific author pages. Maybe checkboxes for all title types on the author page rather then setting it in user preferences.--Rkihara 18:23, 20 February 2017 (UTC)
The question wasn't choosing which title types to display, but rather displaying ss/novelette/novella separately. It's this that I think would not be good on summary pages. As a preference option, OK maybe. --Vasha 20:55, 20 February 2017 (UTC)
If the intent is to separate excerpts from other SHORTFICTION titles on Summary pages, then I believe they need to be turned into a separate title type. Using "length" values to create separate Summary page sections would go against the basic "one title type = one Summary page section" principle. Ahasuerus 23:43, 20 February 2017 (UTC)
Excerpts are short fiction -- it does not really make sense to have them as a separate type any more than novellas are separate type. At least I cannot see a difference... If we split them in a separate type, then why would not things like half a novel published in a volume go into that same new type? Where do we draw the line? At least as a part of the short fiction, that line is clear. Annie 17:05, 21 February 2017 (UTC)
Yes, sometimes excerpts are carefully selected so that they form a complete short story; more often they actually don't seem complete in themselves. --Vasha 17:39, 21 February 2017 (UTC)

(copied from a side discussion in another section) If excerpt got added to the mix [of length options] it would be hard to "sort" that with the others. Uzume 01:28, 25 February 2017 (UTC)

I think you may be the only one who likes the idea of "excerpt" being a length... everyone else was talking about it being a title type --Vasha 01:32, 25 February 2017 (UTC)
That was not how I read things (but perhaps I misunderstood). As title type seems that seems problematic. As a length, I could usefully apply it to essays and nonfiction (like an excerpt of a bibliographic index, etc.) as well. Uzume 01:43, 25 February 2017 (UTC)
I read it as a support for Length as well :) However to your latest point here: length may be showing when you are working on publications for all titles but if you read the documentation and look at editTitle for example, it is valid only for Short Fiction. Making it usable elsewhere will probably require a lot of other changes (even if it becomes a length). Annie 01:46, 25 February 2017 (UTC)
OK, I can sort of see excerpt as a length, in that I hesitate to assign a length to excerpts -- they don't strike me as "really" being a short story or novelette. But that is the very reason that they seem to me to be a separate kind of thing, not short fiction. Besides, I like the idea of having excerpts be a separate section on summary pages, for which they'd have to be a title type. But maybe I am the only one who wants that. --Vasha 02:15, 25 February 2017 (UTC)

Third party identifiers

Support for third party IDs (OCLC, BLIC, LCCN, BNF, ASIN, Goodreads, etc). This will enable Fixer to submit ebooks without ISBNs, an increasingly common scenario.

Good to have some way of identifying ebooks but most of those you listed are ephemeral. Particularly ASIN. (I don't put ASIN in the notes field of an ebook because there are probably numerous ones most of which will disappear soon.) Goodreads has the advantage that they keep records for out-of-print ebooks (it's their policy not to delete) but they're very unsystematic, their records can get merged with each other, etc. --Vasha 17:49, 20 February 2017 (UTC)
Library IDs (OCLC/WorldCat, BLIC, LCCN, BNF, etc) are generally stable, at least as stable as our IDs. We currently link to them in Notes, which requires crafting URLs manually, an error-prone and time-consuming process. In addition, manually built links can become defunct if/when the third party changes its URLs conventions, as we have seen over the last few years. ASINs may not be quite not as stable as, says, LCCNs, but in most cases they work even years after the data was captured. They are frequently the only way to link to the source of our data. Even more importantly, without ASIN support Fixer is unable to submit ebooks without ISBNs, which are increasingly common. Even major authors publish e-stories without ISBNs these days and Fixer can't do anything about them. Ahasuerus 18:10, 20 February 2017 (UTC)
I would certainly like to be able to use library IDs as identifiers for non-ISBN print books. Having support for that makes sense. But Worldcat doesn't list ebooks -- what about other libraries? --Vasha 18:30, 20 February 2017 (UTC)
Some do, but the intent of this FR is to support third party IDs regardless of whether they are for paper books or ebooks. Ahasuerus 18:46, 20 February 2017 (UTC)
As for automatically importing ebooks, that opens a can of worms. We had an inconclusive discussion a while back about what constitutes an "edition" of an ebook. Personally I would like to see them condensed not too many; the way Goodreads has so many is bewildering and ugly. So if you automatically import them there's have to be manual combining. --Vasha 18:30, 20 February 2017 (UTC)
Fixer has been generating ISBN-based ebook submissions for many years. Submitting ASIN-based ISBN-less ebooks should be no different than submitting ISBN-based ebooks once we add support for third party IDs. Where it will get challenging is if we start using another source of ISBN-less ebooks. Suppose Fixer creates a database record for an ISBN-less ebook whose ASIN is "ABC". 6 months later an editor (or another robot) wants to add a record for a Barnes & Noble ebook whose B&N ID is "XYZ". How can we tell whether it's same version of the ebook, especially if the publisher is not specified and the publication dates are close? OTOH, as long as we stick to ASINs, we should be in reasonably good shape since different ASINs are generally associated with different editions. Ahasuerus 18:56, 20 February 2017 (UTC)
Amazon actually doesn't have every single ebook. Graydon Saunders is a fairly notable example of an author who choose not to offer his books via Amazon because he objected to their terms. --Vasha 20:21, 20 February 2017 (UTC)
Oh, definitely. However, as long as we add these books manually, we are less likely to run into problems. It's the robotic submissions that worry me. I have seen many cases where an ebook was originally added by a human editor without an ISBN -- because Amazon doesn't display ISBNs for ebooks even if they exist -- and then Fixer came along and tried to add the same book using its ISBN. (This particular problem will be alleviated by adding support for third party identifiers.) If we were to start using other online sources to grab ISBN-less ebooks, the problem would become more severe. Ahasuerus 20:35, 20 February 2017 (UTC)

(unindent) I believe the next most interesting item is adding support for identifiers. This is a bit sticky but useful concept. The sticky part comes in where we apply these. I believe you were mostly considering at the pub record level, however, the identifiers in this area are themselves usually defined for the concept of an "edition" (which we have no real records for since our pub records most closely correspond to a printing, save for SFBC). This probably is not a major issue but something to consider. Uzume 21:36, 19 February 2017 (UTC)

True, different catalogs and Web sites create records at different levels. For example, an OCLC record may cover multiple ISBNs. Alternatively, multiple OCLC records may cover the same ISBN. I don't think there isn't much we can do about it. Adding support for third party IDs is the best I can think of. Ahasuerus 19:50, 20 February 2017 (UTC)

Next, there is the issue of untangling ISBNs. Currently, our pub record ISBN field represents an identifying mark of the publication (along with cover price, etc.) and we just sort of play games with it to allow is to link to other sites by using it as an identifier. Uzume 21:36, 19 February 2017 (UTC)

Well, ISBNs were originally supposed to be unique and they are still used as "mostly unique" by the industry, e.g. when ordering books. Of course, as we know, publishers can tweak things like cover art and price while keeping the same ISBN. And sometimes they mess up and reuse an ISBN which they didn't intend to reuse. Still, ISBNs are the only IDs that can be used cross-catalog and cross-site with a reasonably high chance of success. Our use of ISBNs to link to other sites is the way they were intended to be used. It's not perfect -- see the OCLC discussion above -- which is one of the reasons why adding support for third party identifiers is useful.
For example, suppose an editor wants to record that some of our data originally came from OCLC records. At this time the only choices are either to:
  • enter something like "Corrected page count from OCLC 1234567, artist from OCLC 987653", or
  • manually craft URLs pointing to the OCLC records
The second options provides more value but is error-prone and time-consuming, not to mention that URL structures can change over time. Once we add support for third party identifiers, editors will be able to enter OCLC record numbers directly. Ahasuerus 20:05, 20 February 2017 (UTC)

An easy way to untangle this is to run some code on our ISBN fields and move them to ISBN identifiers and keep the original field for verbatim publication catalog markings (including wrong/broken ISBNs, etc.). This way we change the current field to a verbatim publication identification field and move identifiers and external linking to use the newly introduced identifiers (including derived/corrected ISBNs etc.). Then we just have to update documentation to keep the fields separate (I recommend renaming the current field as catalog number and documenting it to apply to cover or copyright page catalog numbers, etc.; we could expand it to allow multiple values but frankly I would say that unneeded and can be covered in the note field). Finally, identifiers are also useful at other levels such as author and/or publisher authority control (e.g., VIAF, LCNAF, etc.), and for tags with regard to subject indexing terms (e.g., LCSH, FAST, etc.). Some identifiers also apply to the work (our title record) level (e.g., Open Library works, Wikidata, etc.). Uzume 21:36, 19 February 2017 (UTC)

Yes, author-based and title-based identifiers are something to consider. Currently we enter VIAF links as "Web sites". If and when their URL structure changes, we will have to change the URLs manually or write a conversion script. If we had author-based third party identifiers, the problem could be resolved in 10 minutes. I agree that they would be nice to have, but I see it as a much lower priority than publication-based identifiers. Ahasuerus 19:32, 20 February 2017 (UTC)
Maybe, but we could for instance move Wikipedia links to go through Wikidata identifiers with links like enwiki/Q982133, frwiki/Q982133 and jawiki/Q982133 for John Norman allowing the links to be translatable (without storing and maintaining all the various links) not to mention other possibilities like enwikiquote/Q982133 (provided the sitelink for such articles exist). Uzume 00:47, 25 February 2017 (UTC)

(unindent) OK, I have been thinking about this -- how about this for an addition to the edit-publication page. Below the ISBN field, the ability to add fields for an indefinite number of other identifiers (a button that says "Add Identifier" or whatever), and next to each of these fields a dropdown list to specify what the identifier is: ASIN, OCLC number, publisher's catalog code, however many options seems useful. (Naturally, the submission would be flagged if you try to submit a number without specifying its type -- and maybe, at least for some of them, could be flagged if it's not a valid format for the type specified.) Would that work? --Vasha 01:52, 2 March 2017 (UTC)

That's actually extremely close to the implementation that I sketched out last year :-) Ahasuerus 03:11, 2 March 2017 (UTC)

Happy New Year, all!

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

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

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

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

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

Fabian

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

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

Fireside Magazine

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

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

isfdb in the news

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

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

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

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

Heads-up about the "Add" buttons

I am working on the following RoadMap item:

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

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

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

Publication merge proposal

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

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

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

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

1973 Time magazine

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

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

Geffen Award

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

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

Can anyone here read Chinese?

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

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

My Pending Edits page updated

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

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

Duplicate Catalog ID warnings

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

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

Potential award to add: Premio Ignotus

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

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

(unindent) Descriptions of each category:

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

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

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

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

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

Fuzzy searching

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

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

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

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

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

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

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

Nominating user Boskar for moderator

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

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


Support

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

Oppose


Comments/ Neutral

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

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

Edit form changes - Part 2

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

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

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

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

New Mistakes

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

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

Udon Entertainment Japanese art portfolios

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

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

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

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

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

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

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

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

proposed canonical name change: Standish James O'Grady

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

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

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

Robert Anton Wilson

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

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

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

Verification for scans, PDFs, etc.

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

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

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

Harry Farjeon's "Exit"

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

Edit form changes - Part 3

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

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

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

Canonical name change: Alfred Tennyson

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

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

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

"Black author" tag

(Moved from [here])

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

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

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

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


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

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

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

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

Using author information in title tags

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

I think this raises a number of potential issues:

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

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

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

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

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

Proposed Help changes

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

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

Here is the proposed language:

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

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

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

Alternative approach: Subjects vs. Tags

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

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

The advantages of this approach are:

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

The disadvantages are as follows:

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

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

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

Proposal: special moderator-monitored page for name corrections

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

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

Show title record's language on publication page as well

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

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

Publication: 2001: Odyssee im Weltraum [German]

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

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

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

Contents (view Concise Listing)

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

Example for a novel:
Contents (view Concise Listing)

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

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

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

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

Contents (view Concise Listing)

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

Example for a novel:

Title Language: English

Contents (view Concise Listing)

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

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

Login Problem

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

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

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

Publication page: changes to the Container Title line

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

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

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

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

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

ISBN-less e-pubs without an ASIN - changes

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

Ken Kelly vs Ken W. Kelly

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

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

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

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

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

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

Marian O'Hearn

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

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

Language to add: Asturian

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

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

ISFDB downtime - 2018-03-18

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

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

Publications monitoring

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

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

nonfiction vs. non-fiction

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

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

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

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

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

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

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

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

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

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

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

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

The Tangled Lands

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

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

Secondary verifications - proposed redesign

(moved from the Bleiler discussion above)

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

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

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

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

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

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

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

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

Ahasuerus 18:35, 23 March 2018 (EDT)

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

Premio Ignotus changes

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

External Identifier search enhancement

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

"My Recently Changed Primary Verifications" changes

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

opinions? choosing translations to link reviews

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

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

J. Gregory Keyes canonical name change

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

Do it.--Wolfram.winkler 07:39, 18 April 2018 (EDT)
I Agree that "Greg Keyes" should be his canonical name. Ahasuerus 10:27, 19 April 2018 (EDT)

The paperback formats again

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

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

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

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

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

The secret life of J. D. Tyler

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

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

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

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

"translator unknown" template

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

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

ISBN warning changed

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

Middle French added

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

SFBC again

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

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

Fuzzy dating

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

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

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

Notes and Annotations

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

Particular points

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

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

Edit Form changes - 2018-04-07

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

"Add" buttons are about to be moved

As per Roadmap 2017, we were going to:

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

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

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

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

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

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

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

The X in ISBNs

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

I think we have an FR for this, but I can't check at the moment because the ISFDB part of SourceForge is currently down. We couldn't (easily) do it in the past because ISBNs and catalog IDs shared the same field, but it should be doable now. Ahasuerus 15:09, 10 April 2018 (EDT)
And here it is -- FR 96. Ahasuerus 15:36, 10 April 2018 (EDT)
Done! Ahasuerus 17:43, 10 April 2018 (EDT)
Awesome! Such speedy service. :D ···日本穣 · 投稿 · Talk to Nihonjoe 18:11, 10 April 2018 (EDT)
We do our part! :) (Which would probably be a lot bigger if I were a few decades younger, but it is what it is. Perhaps, like the Terminator, I just need a vacation.) Ahasuerus 18:37, 10 April 2018 (EDT)

Author/Title Language Mismatches report

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

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

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

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

Ahasuerus 15:35, 10 April 2018 (EDT)

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

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

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

The Unteleported Man

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

Linking templates

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

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

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

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

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

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

Is that right?

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

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

Penguin Books and Penguin Books (US), for instance

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

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

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

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

External IDs and book images

Two quick questions from my To Do list.

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

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

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

My thoughts:
Regarding OCLC - if everything else matches, I would link to the record (and if the cover differs, I would mention so). Restricting to non-image only records will remove a lot of good links in the system. So yes - images are great but they are less important than the rest of the details.
For the ASIN question - for pre-ISBN books, if the record does not look too shabby, I will add the ASIN. For books that have ISBNs, I would not add an ASIN link unless I am using the specific record as part of the source for the record even when the book is issued a B ASIN (the ASIN of an ISBN book should be the ISBN10 but there are some exceptions). Annie 22:51, 11 April 2018 (EDT)

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

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

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

My Recently Changed Primary Verifications - Catalog IDs added

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

"Taste of Wrath" length

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

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

URL duplication disallowed

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

Potential Advanced Search enhancements

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

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

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

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

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

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

Webpages links at the Internet Archive

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

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

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

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

Adding Low German

Hello everyone.

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

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

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

Development server update

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

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