ISFDB:Community Portal

From ISFDB

(Difference between revisions)
Jump to: navigation, search
(Moderator Note is now required when editing PV'd publications)
({{FR|794}} Add a 'printing' field to publication records)
Line 1,698: Line 1,698:
:::::::: 2. in most 'special' cases as discussed above we can go with 'as is printed in the book', but what should we do with the line number in US/UK pubs? Would we be copying it as-is in the printing field (which isn't helping readability), or would we go with 'abbreviating' it to the number only and enter that? We'd need some standard so as not to get an ugly mess of one editor handling line number one way, and another a totally different way for the same title (need to be consistent within a title, not necessarily so across different titles, eventhough that'd be preferred, of course)... [[User:MagicUnk|MagicUnk]] 16:52, 13 January 2020 (EST)
:::::::: 2. in most 'special' cases as discussed above we can go with 'as is printed in the book', but what should we do with the line number in US/UK pubs? Would we be copying it as-is in the printing field (which isn't helping readability), or would we go with 'abbreviating' it to the number only and enter that? We'd need some standard so as not to get an ugly mess of one editor handling line number one way, and another a totally different way for the same title (need to be consistent within a title, not necessarily so across different titles, eventhough that'd be preferred, of course)... [[User:MagicUnk|MagicUnk]] 16:52, 13 January 2020 (EST)
::::::::: I'm happy to see the sorting drop aside. So for the Tarzan examples (pardon my date ordering of the special), I'd go along with (and actually prefer) to make the printings numerical where possible (e.g. ''13'' vs. ''Thirteenth''). Some considerations for explaining the use of the field should cover a) distinguishing variant printings (e.g. ''1 Canadian'' and ''1 US'' / ''USA'' / ''America'' / ''U.S.'' / ''U.S.A.'' / ''United States'' / ...) and reuse of printing numbers (e.g. ''1 Special'' / ''Special 1''). ../[[User:Holmesd|Doug H]] 08:33, 15 January 2020 (EST)
::::::::: I'm happy to see the sorting drop aside. So for the Tarzan examples (pardon my date ordering of the special), I'd go along with (and actually prefer) to make the printings numerical where possible (e.g. ''13'' vs. ''Thirteenth''). Some considerations for explaining the use of the field should cover a) distinguishing variant printings (e.g. ''1 Canadian'' and ''1 US'' / ''USA'' / ''America'' / ''U.S.'' / ''U.S.A.'' / ''United States'' / ...) and reuse of printing numbers (e.g. ''1 Special'' / ''Special 1''). ../[[User:Holmesd|Doug H]] 08:33, 15 January 2020 (EST)
 +
Magazines can sometimes be reprinted years later. Since we treat magazines as editor title series (instead of pub series which I believe is a better method; I am not advocating removing editor records or their series), we sometimes see our records in strange organizations like: {{T|1396816|Amra - 1959}} and {{T|1980892|Amra - 1959 (facsimile)}}. {{P|562683|Amra, Vol. 2, No. 2}} did not get re-edited from {{P|379412|Amra V2n2, March 1959}} or even from {{P|380976|Amra V2n2, March 1959}}. The reason someone did that was to help disambiguate between this reprint and the earlier printings (because different editor title records can be in different title series). Using pub series would solve this issue but using a pub record print ranking type of field could also help by allowing a causal viewer to explicitly see in the title record view that certain pub records are tagged with some sort of reprint designation. I believe this field can provide more than just sorting among pub records with the same/indeterminate dates, but it provides a title viewer a better overview of pubs of a specific title. I am not sure it is applicable in all cases but I am not against using a "piped" field type to provide a visual value as well as a sort key value. It also has potential benefits for searching (trying finding a succinct listing of all the first reprintings of the ''Amra'' magazine). With such a field, we could at least find such a listing via a search (although switching to pub series for magazines would have the benefit of also having separate issue grid potential). —[[User:Uzume|Uzume]] 17:01, 15 January 2020 (EST)
== URLs associated with "New Record" submissions are now hyperlinked ==
== URLs associated with "New Record" submissions are now hyperlinked ==

Revision as of 22:01, 15 January 2020


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



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


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




Contents

Question about the Twilight Zone Universe lists

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

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

Templates for incomplete contents

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

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

Leading and Trailing spaces in External IDs

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

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

New User

Greetings from Algonquin

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

What is the purpose of isfdb.org?

With Best Regards,

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

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

Add the rest of the Amazons where they are missing

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

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

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

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

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

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

Series content counts

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

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

New cleanup report - Publication Series Names That May Need Disambiguation

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

Displaying title tags on the Advanced Search Results page

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

If you use Advanced Title Search and one or more of the results have too many tags, the tags column squishes the rest of the fields and takes over most of the screen. Here is an example.
Can we add a new user preference (similar to the "Do not display bibliographic warnings on Title pages") that controls if a user sees the tags in advanced search at all? This way if someone really does not care about the tags can stop them from cluttering the page.
Alternatively, we could set a hard width for the column using a percentage. ("Specific pixels width" wouldn't work for phones.)

Earlier today User:ErsatzCulture proposed the following solution:

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

NoTagCriteria.png

WithTagCriteria.png


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

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

Signing notes

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

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

'Incomplete' template created

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

Checking the database, I see that we have:

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

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

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

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

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

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

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

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

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

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

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

Series and international names

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

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

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

Contents section - sorting

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

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


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

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

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

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

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

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

"Other Sites" split

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

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

Display changes requested by Amazon

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

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

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

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

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

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

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

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

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

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

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

New cleanup report -- Mismatched Template Braces

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

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

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

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

Advanced Publication Search - Primary Verification Date added

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

Leading and trailing spaces in External IDs

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

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

Top Voted list changes

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

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

The FR also requests that we:

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

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

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

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

Content field and varianting

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

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

Imadjinn Awards nonfiction category

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

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

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

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

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

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

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

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

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

Awards titles when a title is changed

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

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

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

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

Elantris

Hebrew title

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

Russian, Polish, Thai, and Portuguese releases

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

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

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

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

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

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

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

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

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

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

Flag to mark publisher name is author name?

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

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

Binti: The Night Masquerade

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

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

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

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

This is annoying in scenarios like the following:

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

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

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

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

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

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

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

The Russian awards

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

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

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

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

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

Who's the image source?

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

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

The Marvel series reorganization

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

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

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

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

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

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

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

A proposal to solve the art battles

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


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

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

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

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

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

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

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

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

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

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

'Add Artist' buitton

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

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

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

Split publications outside of magazines

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

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

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

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

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

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

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

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

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

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

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

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

Linking to outside websites

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

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

Help page update: Chapbooks and Serials

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

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

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

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

Night's Dawn Trilogy (paperback) series

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

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

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

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

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

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

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

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

Vladimir Colin Award

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

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

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

Misdated titles: new cleanup report needed

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Login issues and notifications

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

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

 Login successful
 A confirmation code was sent to your e-mail address. This code is not required to log in, but you will need to provide it before enabling any e-mail-based features in the wiki.
 Welcome, Lukekendall!
 Your account has been created. Don't forget to change your ISFDB preferences.


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

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

Novellas and serialization in chapbooks

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

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

Thanksgiving holiday in the US

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

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

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

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

Del Rey Ballantine

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

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

French Perry Rhodan series

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

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

Wording of text printed by "Incomplete" template

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

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

Wording of text printed by "Incomplete" template - Outcome

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

Rudimentary "Edit History" implemented

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

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

Titles and images for interior art

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

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

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

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

In which I die at the end...

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

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

Moderator note on Publisher Edit

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

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

Clarkesworld - merging the two separate series

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

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

ISFDB On Browser

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

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

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

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

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

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

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

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

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

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

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

'Title Dates after Publication Dates' enhanced

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

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

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

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

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

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

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

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

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

Variants dated before their parents

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

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

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

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

Necroscope

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

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

Publisher Signed First Editions

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

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

Delete Data, change formulations, wrong data

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

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

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

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

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

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

Adding a repeatable "Web Pages" field to Publication records

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

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

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

Nominating user MagicUnk for moderator

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

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

Support

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

Oppose

Neutral/Comments

Outcome

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

SERIALs added to "Title Dates Before First Publication Date"

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

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

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

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

Ahasuerus 14:10, 28 December 2019 (EST)

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

Stone Arch Books's DC chapter books

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

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

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

Anthology : Collection grey area?

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

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

Publisher Directory is incomplete

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

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

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

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

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

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

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

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

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

Echopraxia - Peter Watts - 1st Tor edition cover

I have a problem with the cover scan here. Using Amazon's Look Inside (the 'Print Book' tab) here [3], one can see the different text placement.

The question is, which cover is 'right'? Thanks, Kev. BanjoKev 10:06, 1 January 2020 (EST)

Our record is primary verified by three people. I would assume one of them would have noticed if the record has the wrong cover. The uploaded cover was scanned by one of those verifiers and it looks like a scan of the book itself (there is some distortion on the right that is consistent with curve of a dust jacket). It's possible that there are two different versions of the cover. If you click on the Amazon listing for the tp, you will also see a third location of the text. Basically, I would trust the verified version over the Amazon versions (even with Look Inside, there can be differences between the samples and the real versions). If someone actually has a h/c with another cover, a new record can be created at that time. -- JLaTondre (talk) 10:22, 1 January 2020 (EST)
Thanks. The existing PV'd cover is the same as the OCLC/Worldcat # cover that Bluesman SV'd and that Hauck uploaded 9 days later. So that checks out ok.
This raises the validity of the Amazon version (or any Look Inside data, for that matter). Do you mean that Amazon versions are to be treated as 'not real' as in they may be pre-publication scans/data files they get from the publishers. Please explain. (I do understand that information obtained from Look Inside should be noted as such in publication Notes)
This whole enquiry line started because I have the Head of Zeus 1st printing (which I've started to edit here with only cover scan and OCLC/Worldcat check so far).
In this printing are the following contents, as I would wish them to appear.
  • 13 * The Crown of Thorns: External Layout * (2014-08-00) interior art by Peter Watts [as by uncredited]
  • 15 * Echopraxia * [Blindsight / Firefall * 2] * (2014-08-00) * novel by Peter Watts
  • 358 * Echopraxia Notes and References * (2014-08-00) * essay by Peter Watts
The interior art and essay are referenced in the Notes here - only the once amongst the Echopraxia titles, but not given in the Contents there. The page numbering Wjmvanruth notes for them is exactly as in my printing. The Essay is given in the Contents for all three Firefall titles.
So... at present, we don't have any Contents-listed original publishing dates for either the interior art or essay, despite a version on Look Inside that tells us that Tor did publish them in 'some version' of hc and that, according to my Head Of Zeus 1st edition, HoZ reproduced the whole book with the same page numbering as Tor. Hmmmm. Kev. BanjoKev 15:02, 1 January 2020 (EST)
Quick note: confirming that essays between Echopraxia and firefall pubs are the same (or not) can easily be confirmed by having PVs comparing text (fragments). MagicUnk 17:38, 1 January 2020 (EST)
Regarding your question on Amazon Look Inside: I have seen differences between the Look Inside and the physical book before. I know the Look Insides are provided by the publisher (for physical books; for Kindle versions, I would assume it's a preview of the actual Kindle file). I assume in these cases the publisher provided a softcopy to Amazon, but than made changes before printing. Don't know for sure. In my opinion, if we have a verified publication, I would not create a new publication record based on a small delta like this unless there is something in the Look Inside that indicates it's a new printing / edition. If we didn't have a primary verified pub, I would say update the record to match the Look Inside (with the appropriate pub notes on source) as the vast majority of the time the physical version and the Look Inside are the same. -- JLaTondre (talk) 08:38, 3 January 2020 (EST)

Mechanismo & Wyst: Alastor 1716

Hello Biomassbob, Willem H., Stonecreek. Rather than posting on each individual's talk page, I thought I'd post my question here :). The Glossary for Mechanismo is recorded as SHORTFICTION. However, we generally record glossaries as ESSAYs instead. Could you check your PV'd copies and confirm that indeed it should be recorded as an ESSAY, and adjust the record accordingly (and if it really -is- a short story, add additionally clarify in the title's notes)?
Same for Jack Vance's glossary for Wyst: Alastor 1716 Thanks! MagicUnk 06:23, 2 January 2020 (EST)

I have added notes to each of these glossaries substantiating why they are appropriately considered SHORTFICTION, rather than ESSAYS. Neither is a short story, both are a series of very short stories. The Wyst section establishes the basis for the three books in the Alastor series; the Mechanismo glossary writes very short stories about each artwork in the pub, so far as I know original to this volume. Bob 14:35, 2 January 2020 (EST)
Thanks! I noticed you typed "Glassary" here - I assume that's a typo? :) MagicUnk 06:47, 3 January 2020 (EST)
I agree with Bob. We have a help text here under SHORTFICTION and ESSAY explaining it's the choice of the editor which type to use. If we use SHORTFICTION, no lengte is assigned, to indicate it's not a story. --Willem 14:42, 3 January 2020 (EST)
And so do I. Thanks for clarifying, Bob! Christian Stonecreek 15:03, 3 January 2020 (EST)
Fixed glassary. I'm well known for my many typos (sadly). Bob 21:53, 4 January 2020 (EST)

FR 794 Add a 'printing' field to publication records

As requested at Rules and standards discussions#Date Precedence with '00' Dates by User:Ahasuerus, here is a Community Portal discussion about this feature request.

I personally am of the persuasion that we want such a field and it need not be a numeric field and instead a general text string is probably the best. I also believe we should include some useful Help/advice about how it should be used. I believe we want a "stated" revision/printing/issue type of value that can be used as a supplement to date since in many cases there is no stated date for specific printings.

In the case of assumed printings we might be able to use to same field, however, there should be very good reliable source for such an assertion otherwise it is just noise and would be better in the note if anywhere.

Uzume 17:35, 3 January 2020 (EST)

We could also add some sort of print/issue rank typing field to go with this allowing one to select "via statement", "via number line", "assumed; see pub note for evidence", etc. I recommend the issue rank type field be limited in value much like format and pub type are.

I believe this could be useful for simplifying reprints of magazines as well (instead of creating new editor title records and new series).

Uzume 12:51, 6 January 2020 (EST)

I have reviewed the FR and prior discussions. My take on what is achievable is as follows:
1. The use of a 'printing' field would be the visualization of what printings are already in the database, thus avoiding duplicate pub records by mistake, and a quick way to see which printings are still missing.
2. It is to be used to sort pub records (date, publisher, printing) - note that the 0000-00-00 records must be sorted separately from the dated entries to ensure they are appended at the bottom of the list (ie sort dated records UNION sort unknown date records - if memory serves :). Imo with the available information in the pub records there's no algorithm that can interweave the undated records into the dated records in a way that makes sense, so the UNION is the best we can do.
Some thoughts:
  • To ensure proper sorting, the printing field must be numeric; alphanumeric field would allow for erroneous entries such as a 1st printing pub record having 'A' as printing rank, and a 2nd printing having '2' as printing rank would be sorted '2' first, then 'A' while it should have been the other way around - actually, I can't think of an example where a non-numeric printing would be required?
    • Even if 'as printed' alphanumeric printing rank exists, I suggest to cover a conversion to numeric sequence in the rules
    • Related to that, the printing field cannot hold 'as printed in the book' values, because what to do with number line? Copy it over into the printing field because that's what's on the copyright page? It would make the pub list unreadable very quickly. Better to only copy over the number (ie second printing by number line translates from 3 5 7 9 10 8 6 4 2 to simply '2', for example)
  • At least for (recent) UK/US/... publications, this approach would work quite well, as it'd be a simple translation of the number line.
  • Dutch titles are notorious for maintaining printing sequence across editions (even across publishers) - at least for me, having a printing field would make it much easier to manage all these different printings. A numeric printing would work for the Dutch case equally well.
    • What about German, French, other languages? Would a numeric printing field work? (and if not, why not?)
  • If we don't have a copy of the book, or the book doesn't have the printing info, we have to allow for secondary sources: again for the Dutch case, a quite reliable source of printing information is the Dutch Bibliography (PPN) - see Het zwaard van Shannara for an example
  • Not a fan of an additional rank 'type field' - this info is better recorded in the notes imo
  • I believe the above covers what Uzume requires - except perhaps for the 'as stated' and additional 'rank type' field parts.
I for one would love to see a 'printing' field implemented rather sooner than later :) Thoughts? MagicUnk 13:02, 6 January 2020 (EST)
Something else: it -is- possible, and must be allowed, to have the same printing rank multiple times, if that's how it's stated in the publications - see comments in FR 794 for examples. To be clear: I am not advocating to have a printing rank derived by the editor: it should be as stated in the book (numericalized), or if not available, from 'reliable' secondary sources such as National Bibliographies MagicUnk 13:36, 6 January 2020 (EST)
I do not see the value in forcing a "numericalization" of issue/print ranks. What is the numerical print rank in a magazine issue reprint? How does one "numericalize" the print rank of a Japanese or Chinese book with a stated printing of some kanji character which may have no conceivable ordering (e.g. 下 is a common character meaning "down" and is sometimes used for ordering but its numerical value would not be able to be created in a straightforward way as it often just means "last"). String values can be sorted without any problems and forcing editors to come up with numerical values does not seem to add much value beyond attempting to keep people from entering random garbage. This is what submissions and moderation is for. I would advocate moderator warnings on submissions with print ranks we do not expect.
It should not be difficult to add a cleanup report looking for pubs with the same publisher, date, and format, etc.
Uzume 15:43, 6 January 2020 (EST)
First, let's agree on what the print rank is intended for: to be able to sort printings with 'same date-same publisher' (which would include the 0000-00-00 case), AND, to convey (from the title screen) which printings are already in the database. On second thought, doesn't have to be converted to an (integer) number per-se, provided the sorting functionality can still be achieved, preferably in a consistent manner (to be supported by rules on how to obtain/derive/enter the print rank to ensure sorting is not thwarted). And to refine my earlier statement: print rank -can- be derived provided there's no actual printing information in the book itself and if certain criteria are met (see below). Or if available then the 'as-printed' info must be recorded (with allowance for an abbreviated 'numericalized' notation, such as number line --> single-digit print rank).
Are we all agreed that that is what we want to achieve/use them for?
BTW, and to be clear, I still think the 'numericalization' is the least error-prone approach imo as it would guarantee that I can achieve what I want, as illustrated below.
Second, to your examples, can you elaborate please? I am unfamiliar with magazine re-issues to fully understand what you are trying to say. Any actual examples? As far as I can see, there are two possibilities:
1. A. there is a first print run (and gets distributed), and then a couple of days/weeks/months later, there's a second print run of the same issue (and that gets distributed too). Provided there's information somewhere on or in the magazine to discriminate between the two, they would get (a derived) 1st and 2nd printing, respectively.
B. If we can't distinguish at all, the best we can do is add notes to clarify that there are, in fact, two print runs, and record them as 1st print run only (even though they have been printed separately). Or just leave the printing field blank and add a note to clarify, as no useful print rank information can be conveyed anyway - this would have my preference. Or
2. the re-issue is, in fact, a totally different edition (such as e.g. facsimile re-issues of classics many years after the original). For this case I would argue they would be different in more ways than simple print runs - they would likely have different publisher and/or different printing dates and/or different finish (e.g. glossy vs. cheap paper), and so on. These are different publications, each with a (derived) 1st print-run. For this case I wouldn't even bother entering printing number as they'd be clearly distinguishable anyway (but you could if you wanted to).
As to the Japanese/Chinese example; my understanding of what you are saying is that you can have several print runs (presumably potentially with different printing dates?), all with the same print run information (ie. the character 下 in your example). Again, two possibilities I can see:
1. if there's no additional information on or in the book or anywhere else to otherwise discriminate between print runs, then don't bother entering a print rank (indeed, what's the value of recording 'last' multiple times? I don't understand what it means in context of print-runs?) I.e. barring additional information to allow to discriminate, we're stuck. If there are dates, then fine, sorting will sort itself out :). Or,
2. if there -is- additional information on or in the book that allows to distinguish which print-run was first, we'd record the derived print rank (and clarify in the notes, as appropriate).
As I believe that you propose to restrict to only record 'as-printed' printing information, you wouldn't be able to sort nor convey what print runs are already in the database, while deriving a ('numericalized') print rank could. Or am I misunderstanding you? If so, can you detail what your proposal would entail and how it would work, perhaps with some use cases? MagicUnk 05:57, 7 January 2020 (EST)
There is one other wrinkle to the "numeric vs. non-numeric values" debate. I vaguely remembered that many Russian publishers handled printings differently, so I decided to check FantLab. According to this FantLab record, the 2001 edition of this novel had the following "additional printings":
These "additional printings" were apparently not numbered. Moreover, some were associated with multiple ISBNs because they were published by different imprints of the same publisher (АСТ). Are they really "printings" as we understand them? If they are, can we assign sequential numbers to them even though they are apparently not numbered by the publisher? If we do, will the four different 2005 ISBNs share the same printing number (5)? Ahasuerus 18:55, 6 January 2020 (EST)
They are printings in the same way as the US numbered ones are. They may have different covers and/or copyright pages to account for the added ISBNs and some of them switch ISBNs completely but they are printings - the Bulgarian books have the same logic. The problem with adding sequential numbers is that as they are not numbered, a missing one may be identified later on if we grab data from an incomplete entry -- thus messing up our numbering. So if we are sure of the data, we can add numbers (and I had added to some books); but if we are not, there is a chance that there is a missing number somewhere in between... And the year is not always enough either see this one which has 3 printings in 2006 alone. Annie 19:19, 6 January 2020 (EST)
Agree that this is a potential source for erroneous data entry if somehow you've missed a printrun in-between. Annoying for sure, but I don't see how we can prevent this from happening. However, I believe it's not such a big an issue since once the missing in-between printrun is discovered, it is easy enough to insert the new one with its (numerical) printing (assuming we go with that), and correct the other printings accordingly. The only non-trivial (corner?) case is where you have the same year (as in Annie's example). Barring additional information (such as perhaps month/day somewhere else? - Annie, is there a way to discriminate the order in which these 2006 runs were printed?) there's no way to disambiguate. Recording these ambiguous cases with the same printing, accompanied with a note explaining the issue, could be a possibility - after all, if recorded this way, sorting would still be correct (ie all 2006 runs are below each other). Not perfect, but it would work for our purposes, no?
And if there would be no date (ie for the 0000-00-00 case) we're stuck, and we'd have to leave the printing field blank. (but hey, no printing information is also information :) Anyway, I wouldn't want this case to prevent us from having a printing field :). MagicUnk 05:57, 7 January 2020 (EST)
Russian (and Bulgarian) printings always have an associated "signed for printing" date with them - I think that most of Eastern European books had that at least last century. Not easy to find without the book at hand sometimes but they always exist. It is not the Depot legale of the French but it is usually enough to separate the printings. So the 3 2006 printings are easily separable based on that (when you do not have a better way - more or new ISBNs, separate printer and so on). And later printing often list the previous ones (often being the imperative word).
I still do not feel comfortable us assigning a number based on an incomplete set of data. If we call something second printing, it means "second printing" and not "second printing we know of but we had not done much of a research". We need to be able to stand behind our data and while changing the numbers is easy, knowingly adding incorrect information just so we can make up some numbers is... bad. If we want to have system generated numbers (printing we know of), we can discuss that but mixing genuine numbered printings with "printings we know of" devalues our data. Which does not mean that we should not have the field - just that it needs to be non-numeric. And once we have it, coming up with standards per language/country for the ones we know do not number is not that hard. Bending some data to conform to another country's publishing practices is a bad idea - just witness how long it is taking us to get untangled from the US focus of this DB - while multiple ISBNs and publishers are almost unheard of in this set (or were...), they are common in Russia/USSR; same with multiple prices in the Western European world.
One option may be to have a radio box: Numbered/unnumbered printing which then either allows only numbers (for properly numbered printings) or free text (for the rest).  :) Annie 11:49, 7 January 2020 (EST)

(unindent) Hi Annie, my examples above are just that, examples. While I believe the mechanisms explained to obtain derived printing ranks can be useful in certain cases, they by no means are to be considered given, and in any case must be applied judicially. I would never advocate not to be thorough :) but mistakes are made... It also looks like the discussion is crystallizing out towards a consensus to have a non-numerical printing field, supported by a case-by-case set of rules to apply, probably per language and/or country to be able to accomodate the varied practices out there. This supporting rules' set is then something that we still need to continue to build, as you suggest. In any case, while I remain in favour of a purely numerical field, I have no fundamental problems with using a non-numerical field. On a slight tangent, I haven't seen any examples on how to record the specific cases showcased above. For example, I'd be curious to know how you and Uzume'd envision practically recording the magazine, the Chinese/Japanese, the Russian/Bulgarian, and other practices. Cheers! MagicUnk 13:41, 7 January 2020 (EST)

That will depend a lot on what we decide to do exactly -- how many fields, will we distinguish between derived and stated and how in a separate field and so on. The note above was explaining why a number won't work outside of the numbered practice. And there is another thing to be careful about - where we want to show these. Number only ones will fit almost anywhere (and will be very useful in the pub table under the title for example); the text ones will make that table unmanageable. We may also decide to just ignore the new fields for cases where printing is not well defined. Blocking everything while we find all possible corner cases and agree on all rules had (and would) never worked anyway. I am also just fine not recording the Bulgarian/Russian ones outside of the first in the new fields - if anything, we need the multi-publishers/multi-ISBNs for these a lot more (but that is a different conversation). :) Annie 14:09, 7 January 2020 (EST)
Welll, numbers -will- work outside of the numbered practice provided there's sufficient information available so that a conversion algorithm can be applied and yields unambiguous results. If not, then the numbers will be undetermined and remain blank. We can do that :) There's not really a conflict there and I agree with what you're saying that you can decide not to enter printing information or choose not to (or not required to) apply any conversion. That leads to your suggestion to use an 'as printed' field, next to a derived (numerical) printing field (IIRC this has been suggested in the past too). In that case we would be better off naming the latter 'sorting field' then(?). Ie two fields, which can have the exact same information in case of the numbered practice. That still doesn't answer which of the two (or both?) we'd want to display on what screen(s). So, what about only displaying the 'as printed' field, but with a limited width, say, 10, 15 positions at most, and sorting on the not-displayed sorting field. Would that work for the pub list? Drawbacks? Cases where it wouldn't be workable? (one thing we have to be careful about is that we have to make sure that the solution we end up with remains workeable, ie that data entry does not become too much of a burden to the point of untenable for the editors. Likewise, as you're saying readability is important too ...)
As for sorting in the case of having these two fields, sorting could be done as follows: sort on the 'sorting' field by default, and if for some pubs that field is left blank, use the value from the 'as printed' field. If both are blank, well these records end up at the bottom of the list (not sure if this is clear enough, but it'd be something like SORT(IF sortingField ISBLANK THEN asPrintedField ELSE sortingField) (btw, this approximates your radio-button suggestion :) MagicUnk 15:47, 7 January 2020 (EST)
Any reason not to use a single field that does the same thing the page field currently does (allow any needed text entry with a piped sort). It would keep things consistent. -- JLaTondre (talk) 17:22, 7 January 2020 (EST)
Euh, I'm lost... what do you mean with a piped sort?! Can you explain what you mean by that? Thanks! MagicUnk 11:53, 8 January 2020 (EST)
There are two things here: what we record/show and how that relates to sorting on lists. The sorting can be done via a pipe: so the 3 2006 printings above can have strings such as "2006.1|First 2006 printing" for example. That way you define both how it sorts and what you show at the same time - like we do with pages. Annie 12:07, 8 January 2020 (EST)
See the "Sorting" section of Template:PubContentFields:Page, which discusses the uses of the "pipe" character, for details. Ahasuerus 12:31, 8 January 2020 (EST)
Aaah, yes. Got it :) Fine with me MagicUnk 13:30, 8 January 2020 (EST)
Works for me. Annie 17:34, 7 January 2020 (EST)
Showing how a scheme works for particular examples sounds like a good idea. Can someone explain how you would enter priting/sorting fields for these five printings (of many) for Tarzan of the Apes? 1st (US), 1st (CN), First Special Printing, 13th printing (precedes Special printing), 14th printing follows Special printing. ../Doug H 13:10, 8 January 2020 (EST)
To answer Doug's question: If we assume we sort on date, then publisher, then printing, we wouldn't be able to reorganize the way you requested with the '|' symbol because date sorting takes precedence. In other words, since the dates are all different (except for the first two) the sort order can't be changed - and we even wouldn't want to! (btw, are you sure 13th printing precedes special printing? If so, the current printing dates are in error). So, if you want to sort the first two (wanting the US first), you could enter something like this:
First Printing: July 1963 | 1 (US)
First Printing: July 1963 | 2 (CN)
First Special Printing: January, 1976
Thirteenth Printing: November, 1976
Fourteenth Printing: December 1977
If you would enter something like this
First Printing: July 1963 | 1 (US)
First Printing: July 1963 | 2 (CN)
Thirteenth Printing: November, 1976 | 3
First Special Printing: January, 1976 | 4
Fourteenth Printing: December 1977 | 5
You would still end up with the same ordering displayed for the printing info, like this:
First Printing: July 1963 (US)
First Printing: July 1963 (CN)
First Special Printing: January, 1976
Thirteenth Printing: November, 1976
Fourteenth Printing: December 1977
Again, this is assuming that the piped printing sorting is applied only after sorting on date, then on publisher. Note that this outcome is as expected (date sorting first). Maybe Ahasuerus can chime in with details on alternative implementations of the pipe sorting (as I'm not sure exactly how the current page piping is coded)? MagicUnk 13:09, 13 January 2020 (EST)
One thing to keep in mind about the "pipe sorting" of page numbers is that "pipe" numbers can include decimals. If we decide to use the same algorithm for the proposed "printing" field, we'll be able to use "|1.1" for the first US printing and "|1.2" for the first Canadian printing.
That said, I am still thinking of the best way to capture and display printing numbers. The discussion above suggests that if we continue to sort publications by date, a "printing" field would only change the way we sort publications with the same publication date. In most cases it would be limited to 0000-00-00 publications.
However, sorting issues aside, there is also value to simply displaying the printing number on the Title page. Consider Devon Monk's Magic to the Bone. We have publication records for 4 printings of the mass market paperback edition published by Roc. You have to check all 4 to discover that there have been at least 5 printings and that we are missing the 3rd one. Having the printing numbers displayed on this book's Title page would be very useful, sorting issues aside. Ahasuerus 15:24, 13 January 2020 (EST)
Yes, exactly! :) One thing I've been thinking is that there's no real need for sorting on publisher at all. It should suffice to sort by date, and then by the piped printing (which would, indeed, mostly be relevant for the 0000-00-00 case only). I'd like to have input on:
1. what would be the maximum workable width of the printing field before its contents starts to wrap?, and,
2. in most 'special' cases as discussed above we can go with 'as is printed in the book', but what should we do with the line number in US/UK pubs? Would we be copying it as-is in the printing field (which isn't helping readability), or would we go with 'abbreviating' it to the number only and enter that? We'd need some standard so as not to get an ugly mess of one editor handling line number one way, and another a totally different way for the same title (need to be consistent within a title, not necessarily so across different titles, eventhough that'd be preferred, of course)... MagicUnk 16:52, 13 January 2020 (EST)
I'm happy to see the sorting drop aside. So for the Tarzan examples (pardon my date ordering of the special), I'd go along with (and actually prefer) to make the printings numerical where possible (e.g. 13 vs. Thirteenth). Some considerations for explaining the use of the field should cover a) distinguishing variant printings (e.g. 1 Canadian and 1 US / USA / America / U.S. / U.S.A. / United States / ...) and reuse of printing numbers (e.g. 1 Special / Special 1). ../Doug H 08:33, 15 January 2020 (EST)

Magazines can sometimes be reprinted years later. Since we treat magazines as editor title series (instead of pub series which I believe is a better method; I am not advocating removing editor records or their series), we sometimes see our records in strange organizations like: Amra - 1959 and Amra - 1959 (facsimile). Amra, Vol. 2, No. 2 did not get re-edited from Amra V2n2, March 1959 or even from Amra V2n2, March 1959. The reason someone did that was to help disambiguate between this reprint and the earlier printings (because different editor title records can be in different title series). Using pub series would solve this issue but using a pub record print ranking type of field could also help by allowing a causal viewer to explicitly see in the title record view that certain pub records are tagged with some sort of reprint designation. I believe this field can provide more than just sorting among pub records with the same/indeterminate dates, but it provides a title viewer a better overview of pubs of a specific title. I am not sure it is applicable in all cases but I am not against using a "piped" field type to provide a visual value as well as a sort key value. It also has potential benefits for searching (trying finding a succinct listing of all the first reprintings of the Amra magazine). With such a field, we could at least find such a listing via a search (although switching to pub series for magazines would have the benefit of also having separate issue grid potential). —Uzume 17:01, 15 January 2020 (EST)

URLs associated with "New Record" submissions are now hyperlinked

All URLs associated with "New Record" (New Publication, Clone Publication, New Award Category, etc) submissions are now clickable on submission review pages. Ahasuerus 20:50, 5 January 2020 (EST)

Thank you! -- JLaTondre (talk) 20:35, 6 January 2020 (EST)

Pub record replace titles

I am not sure if this is highly coveted/useful or even how difficult it would be to write/merge/create, however, I often find myself needing to replace titles, meaning both removing and adding (aka import/export content) titles at the same time. Currently the software does not allow this and more than a single submission is necessary to articulate the procedure. I wonder how complex would it be to merge:

  • edit/rmtitles.py
  • edit/clonecontent.py

This might also affect:

  • edit/importcontent.py
  • edit/exportcontent.py

More generally, it might also be possible to add this directly to:

  • edit/newpub.py
  • edit/editpub.py
  • edit/clonepub.py

Which might also affect:

  • edit/clone_intermediate.py

I think it might prove useful to unify all the pub title content editing controls into a single place.

So do you think this sounds useful to you and is not too crazy and daunting? I am looking for feedback (including perhaps better ideas) before submitting a software feature request. Thank you. —Uzume 12:07, 6 January 2020 (EST)

So you are looking for a way to combine "Remove Titles" with "Import Titles, Option 2"? What about the rest of the possibilities (the ability to import a complete other collection for example - Option 1 of the import (import all from a pub))? And do you also envision having the ability to manually add more titles (as you can with Import but cannot during a remove)? And what about cloning? Is the idea to be able to clone and replace/remove during the cloning process itself?
While I would love to be able to import, edit and remove from a single screen, unless we are covering all the options (basically bringing these 3 to a single page), I find them more intuitive as separate options. Annie 12:58, 6 January 2020 (EST)
I am not sure it matters. I was considering both options. As it is, both options have the same "clonecontent" backend. I am proposing to merge the backend with "rmtitles" or better yet with "newpub", "editpub", and "clonepub".
For example, we could have a editpub.cgi?ExportFrom=<pubid> or editpub.cgi?ImportTitles1=<titleid>&ImportTitles2=<titleid> in a similar fashion as we now have with clonecontent.cgi. Further the existing titles could have checkboxes next to them to have them removed much like rmtitles.cgi currently does. "newpub", "editpub", and "clonepub" could have form boxes to apply such form parameters to themselves and be reloaded or something similar to avoid the necessity for separate entry forms like "importcontent" (we could still have those if such things were useful and clearer of course).
Uzume 14:14, 6 January 2020 (EST)
Could you please rephrase the idea in functional terms? Much of what you are suggesting describes proposed technical implementation details, which are meaningless to most ISFDB editors. Ahasuerus 18:08, 6 January 2020 (EST)
Well I was proposing it in steps merging backends (because it might very hard to design and make all that work in one go) but the ultimate goal would be a single pub editor that can do what it does today as well as adding and removing titles. This would work for newpub, addpub, clonepub, editpub and effectively including the functionality of removetitle and import/export content. Is that functionally simple enough? —Uzume 19:48, 6 January 2020 (EST)
Implementation difficulties aside, I suspect that moving the "import titles", "remove titles" and "import from a publication" functionality to the Edit/Add/Clone/New Publication page would make the consolidated page hard to navigate. Ahasuerus 16:05, 7 January 2020 (EST)

Blocking "Add Publication to This Title" for certain title types?

Why are we blocking addpub.py for certain title types. For example why is this "not supported":

It seems like most people would want to add pub record issues to magazine editor title records. Why am I required to add a new magazine (including new title) and then subsequently merge the extraneous editor record that results from that?

According to edit/addpub.py, the currently "supported" title types include only: 'NOVEL', 'COLLECTION', 'OMNIBUS', 'ANTHOLOGY', 'CHAPBOOK' and 'NONFICTION'. Thank you.

For context, I did some searching and this goes back to CVS edit/addpub.py 1.20 and FR 446

I am assuming it is somehow related to this outdated Help:Screen:AddPublication that states one cannot change the contents during the add.

Uzume 14:20, 6 January 2020 (EST)

Thanks for the heads-up re: Help:Screen:AddPublication! I have updated the text to reflect the way the software works in 2020.
Re: the main question, there are three deactivated fields on the "Add Publication to This Title" edit form: "Title", "Author(s)", "Pub Type". It works well for book titles, but magazines are a bit different. The Title field would need to be activated because MAGAZINE/FANZINE publication records and EDITOR title records use different naming conventions, e.g. "New Worlds, #3 (October) 1947" vs. "New Worlds - 1947". The "Pub Type" field would also need to be activated because EDITOR titles are used for both MAGAZINE and FANZINE publications.
Other than that, I can't think of any reason why we couldn't make "Add Publication to This Title" work for EDITOR titles. Ahasuerus 17:44, 6 January 2020 (EST)
Cool, then perhaps we can get an FR to reenable all the other missing title types that addpub used to work years ago before FR 446 broke them in late 2015. Or maybe this would be better as a bug since it used to work and was broken. —Uzume 20:06, 6 January 2020 (EST)
I can see how the ability to "Add a Publication" to an EDITOR title could be useful, but we have to be careful with other title types. Early on, the software let you "Add a Publication" to SHORTFICTION titles, which caused problems. Similarly, adding a publication to a POEM, ESSAY, SERIAL, REVIEW, INTERVIEW, COVERART or INTERIORART title wouldn't work too well. Ahasuerus 15:23, 7 January 2020 (EST)
Well, if we can somehow make "Add Publication" on a short story/poem record create a chapbook record, that will be very useful actually - especially with all those never before reprinted story that keep popping up and with more and more authors making their stories available outside of collections. I'd argue that it will used a lot more than adding a publication to an EDITOR. :)Annie 17:39, 7 January 2020 (EST)
I can see how it could be useful, but there is a catch. A regular "Add Publication to NOVEL/COLLECTION/etc" submission creates a new NOVEL/COLLECTION/etc pub record and links it to an existing title record. An "Add Publication to SHORTFICTION/POEM" submission would not only create a new CHAPBOOK pub record and link it to an existing SHORTFICTION/POEM title, but it would also create a new CHAPBOOK title and link the pub to it. That would be a significant change to the option's functionality.
Perhaps it would be better to create a new option, "Create a CHAPBOOK publication for this title", which would only be displayed for SHORTFICTION/POEM titles. It would help address the issue that we had back when "Add Pub" was available for all title types: editors often tried to use it to "add" collections/anthologies/magazines/etc to SHORTFICTION/POEM/ESSAY/etc titles. Ahasuerus 13:29, 8 January 2020 (EST)
Yeah, that works as well and makes sense - as long as we do try to do something. AddPub is easily replace-able with ClonePub when we have at least one publication anyway so I rarely use AddPub (I use it mainly when I am adding the first pub to a pub-less parent for example) but I can see how it can get confusing if we add it back to the Short fiction and poem types (and SERIAL... let's not forget SERIAL) :) Annie 13:45, 8 January 2020 (EST)
It sounds like we need two separate FRs then, one for adding pubs to EDITOR titles and another FR for adding chapbooks to SHORTFICTION/POEM/SERIAL titles. Ahasuerus 19:47, 8 January 2020 (EST)
Yep - probably better to keep them separate. Annie 19:50, 8 January 2020 (EST)

(unindent) FR 1331 and FR 1332 have been created. Ahasuerus 14:27, 13 January 2020 (EST)

Alphabetical author order -- wrong preposition?

I was looking at something else and noticed that we use a different preposition (and view) in the alphabetical order compared to the Chronological. See the chapbooks here. The ones that say "with Conrad Shepherd" are actually "AS Conrad Shepherd" and why do we show them separately anyway (compare to the chronological view where they are in the usual "only by" format. It is not just the chapbooks - but it is easily visible with them. Am I missing something that we are trying to achieve here? Annie 16:45, 7 January 2020 (EST)

That would be Bug 491 :-) Ahasuerus 18:38, 7 January 2020 (EST)
Any plans on getting it fixed one of those days? Because this is beyond ugly - not to mention that it is the only interface that actually shows the data differently. This one looks even uglier... :) If the Chronological list keeps the variants under their parents, why does the alphabetical one flattens them - I would expect the two lists to be exactly the same, with the order changed... Annie 19:23, 7 January 2020 (EST)
It's the single biggest bug left in the system. Unfortunately, I need to massage the way author pages are built -- without messing up anything else -- in order to fix it. I didn't want to tackle it while I wasn't feeling well, but I may be in good enough shape to try it this month. I'll see what I can do. Ahasuerus 22:25, 7 January 2020 (EST)

Publications with Wiki pages

The cleanup report Publications with Wiki pages has been adjusted to work with the new "Publication Web Pages" multi-field. Once the nightly job runs at 1am server time, I expect the number of flagged publications to go from 236 to 295.

As we discussed 10 days ago, some Wiki-based pages for existing publications (like this one and this one) will need to be folded into regular Note fields. When this report is out of the way, we can re-assess where we are and create additional cleanup reports.Ahasuerus 21:33, 7 January 2020 (EST)

A new cleanup report to find pubs which use the 'Incomplete' template

A new cleanup report to find pubs which use the 'Incomplete' template has been deployed. As per FR 1312, it uses the same grid format as the cleanup reports which find container pubs with no fiction titles. The data for this report will appear once the nightly job runs in about 6 hours. Ahasuerus 19:45, 8 January 2020 (EST)

2020-01-11 - Performance problems

Earlier today the server was mostly unresponsive due to identified technical issues. Everything seems to be back to normal now, but we don't know what the problem was. We are still looking into it. Ahasuerus 14:19, 11 January 2020 (EST)

It's still happening, although sporadically. I have asked to have the whole server rebooted. Ahasuerus 16:19, 11 January 2020 (EST)

L. E. Modesitt, Jr. - Recluce Maps

Hi, i'about to add the german translations of the Recluce series. Book 5 to 13 have maps by Ellisa Mitchell and some of the original pubs have them too. As far as i can see they are all identical - at least in the translations - and a quick Amazon "look inside" check on a few shows this also seems to be the case for the originals. If so, shouldn't one of them be a parent title and the others varianted to it? So before i add the translations and variant the maps to nine different titles i'd like to ask if anyone would be able to check if the maps in the original pubs are indeed all the same? Werner Welo 06:34, 12 January 2020 (EST)

I wondered about how to approach recurring maps, but only got as far as noting a couple of links to check - Using a series title and use of images. I'll be adding this discussion to my set. ../Doug H 10:14, 12 January 2020 (EST)
If they are indeed recurring, it may be better to merge them and set the title to 'Recluce Saga (map)' or something similar. At least they have to be varianted to a parent (likely the first occurrence). Stonecreek 13:00, 12 January 2020 (EST)

Moderator Note is now required when editing PV'd publications

As per FR 1321, a Moderator Note is now required when editing publications that have been primary-verified by users other than the submitting editor. You may need to do a full page reload (Control-F5 under most browsers) to get the new functionality working correctly. If you come across any oddities, please post your findings here. Ahasuerus 17:40, 12 January 2020 (EST)

How does this affect other submission types that affect PVed records like title submissions, etc.? I can see some situations where requiring our existing "Moderator Note" (however we decide to re-name it) for even all pub edit submissions against PVed pub records, might not be the best approach. For example, if I only want to add/fix external identifiers for a pub record. These normally have little to no bearing on the actual physical publications (we sometimes see LCCNs printed in publications but I have not heard of cases where they contain BNB, JNB, OCLC or other identifiers much) and I do not see why a PVer need be much involved with such a change. I expect a PVer to probably know about the same as others on that front. And normally an external identifier change is highly self-explanatory even for a moderator much less a PVer or any other editor/reviewer (so what do you propose I start putting in these required "Moderator Note"s?). The same could be said for the new web page links that are now allowed on pub records. These too have little bearing on the actual physical publication which is what PV is all about and a web page link is usually pretty self-explanatory. —Uzume 16:12, 15 January 2020 (EST)
Personal tools