ISFDB:Community Portal


Jump to: navigation, search

ISFDB Noticeboards
Before posting to this page, consider whether one of the other noticeboards might suit your needs better.
Help desk
Questions about doing a specific task, or how to correct information when the solution is not immediately obvious.
• 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


Shona added

The Shona language has been added to the list of supported languages. Ahasuerus 11:30, 5 September 2018 (EDT)

The Legend of the Ice People

According to Wikipedia, Margit Sandemo's 47-volume The Legend of the Ice People contains "some fantastical elements". Would anyone be interested in entering it? Ahasuerus 13:12, 6 September 2018 (EDT)

I added another 110+ volume series, so I can handle it. ···日本穣 · 投稿 · Talk to Nihonjoe 18:27, 9 September 2018 (EDT)
Done. The Swedish Wikipedia lists it as a fantasy series. It's been added here. The author has also been updated. ···日本穣 · 投稿 · Talk to Nihonjoe 20:18, 9 September 2018 (EDT)
Thanks! Ahasuerus 20:52, 9 September 2018 (EDT)

Old Norse

I've come across a translation of a poem from Old Norse. Would it be possible to add it to our supported languages? Thanks. --Ron ~ RtraceTalk 09:41, 8 September 2018 (EDT)

Old Norse is an ISO 639-2-recognized language. I should be able to add it once I finish the weekly backups. Ahasuerus 10:35, 8 September 2018 (EDT)
Done! Ahasuerus 13:11, 8 September 2018 (EDT)
Thanks! --Ron ~ RtraceTalk 15:13, 8 September 2018 (EDT)

Infrequent languages: adding more?

I am thinking of entering Jalada Translation Issue 01, which is a fable by Ngũgĩ wa Thiong'o translated into more than 30 languages, mostly from Africa. The ones we don't already have are Gikuyu, Dholuo, Kikamba, Lwisukha-Lwidakho, Luganda, Ikinyarwanda, Meru, Lingala, IsiZulu, Igbo, Ibibio, isiNdebele, XiTsonga, Nandi, Rukiga, Bamanankan, Lugbarati, Lubukusu, Kimaragoli, Giriama, Sheng, Naija (Nigerian Pidgin), Dhopadhola/Adhola, Igala, Marakwet, Ewe, Setswana, Ebira, Sesotho, Kreol Morisien, Sepedi, Fombina, Kipsigis, Acholi, Tigrinya, Tigre, Dagaare, Ekegusii, Tamazight, Teso, Kannada, Odia, Kurdish, and Mixtec/Tu’un sávi. Also, the story appeared in Mandinka, Wolof, and Fula in another publication which I may be able to find information about.

Is it problematic to make the list of languages very long by including ones that have very few works published in them? Perhaps we could do like Goodreads does and have a separate section for frequently-used languages at the top of the list. --Vasha (cazadora de tildes) 12:49, 9 September 2018 (EDT)

I guess the first thing to do is to find these languages' ISO 639-2 names and codes. It's not always straightforward, e.g. "Gikuyu" is listed as "Kikuu/Gikuyu" and "Dholuo" is listed as "Luo" (see Wikipedia.)
If it turns out that some of them are not a part of the ISO 639-2 standard, then it will pose a different problem: we currently defer to ISO 639-2 for language identification and naming purposes. In the past we considered using ISO 639-3 instead, but it raised other questions like "who determines what is a language and what is a dialect?" In the end we decided to stick with ISO 639-2.
If we determine that ISO 639-2 has become too limiting for our purposes, we'll need to revisit the issue and pick the brains of our more language-savvy contributors. Ahasuerus 13:17, 9 September 2018 (EDT)
Indeed, some of these languages are only in ISO 639-3. Also, Sheng is not even recognized by Ethnologue and ISO because it is a cant (argot) -- I suppose you could just include it in Swahili as a variety of that language. --Vasha (cazadora de tildes) 14:12, 9 September 2018 (EDT)

African Languages - ISO names and codes

Language ISO Codes
ISO Name Name in Ruhlen Name in Jalada ISO 639-2 ISO 639-3
Acoli Acholi Acholi ach ach
Adhola Adhola Dhopadhola ssa [Nilo-Saharan languages] adh
Bambara Bambara Bamanankan bam bam
Bukusu/Lubukusu not mentioned Lubukusu bnt [Bantu languages] bxk
Chiga not mentioned Rukiga bnt [Bantu languages] cgg
Ebira Ebira Ebira nic [Niger-Kordofanian languages] igb
Ekegusii/Gusii Gusii Ekegusii bnt [Bantu languages] guz
Ewe Ewe Ewe ewe ewe
Fulah Fula Fula ful ful
Ganda Luganda Luganda lug lug
Giryama/Kigiryama Nyika Giriama bnt [Bantu languages] nyf
Ibibio Ibibio Ibibio nic [Niger-Kordofanian languages] ibb
Idakho-Isukha-Tiriki/Luidakho-Luisukha-Lutirichi not mentioned Lwisukha-Lwidakho bnt [Bantu languages] ida
Igala Igala Igala nic [Niger-Kordofanian languages] igl
Igbo Igbo Igbo ibo ibo
ISO 639-2: Kamba
ISO 639-3: Kamba (Kenya)
Kamba Kikamba kam kam
Kannada Kannada Kannada kan kan
ISO 639-2: Kikuyu/Gikuyu
ISO 639-3: Gikuyu/Kikuyu
Kikuyu Gikuyu kik kik
Kinyarwanda Rwanda Ikinyarwanda kin kin
Kipsigis Kipsikiis Kipsigis ssa [Nilo-Saharan languages] sgc
Kurdish Kurdish Kurdish kur kur
Logooli/Lulogooli Logoli Kimaragoli bnt [Bantu languages] rag
Lingala Lingala Lingala lin lin
Lugbara Logbara Lugbarati ssa [Nilo-Saharan languages] lgg
ISO 639-2: Luo (Kenya and Tanzania)
ISO 639-3: Dholuo/Luo (Kenya and Tanzania)
Luo Dholuo luo luo
ISO 639-2: Mandingo
ISO 639-3: Mandinka
Mandinka Mandinka man mnk
Markweeta Markweta Marakwet ssa [Nilo-Saharan languages] enb
Morisyen Kreol Morisien cpf [Creoles and pidgins, French-based] mfe
Meru Meru Meru bnt [Bantu languages] mer
[one of the Mixtec languages] Mixtec Tu'un sávi cai [Central American Indian languages]  ???
Nandi Nandi Nandi niq niq
ISO 639-2: Fulah
ISO 639-3: Nigerian Fulfulde
Fombina ful fuv
Nigerian Pidgin Naija Languej cpe [Creoles and pidgins, English-based] pcm
Northern Dagara Dagara Dagaare nic [Niger-Kordofanian languages] dgi
ISO 639-2: Oriya
ISO 639-3: Odia/Oriya (individual language)
Oriya Odia ori ory
ISO 639-2: Pedi; Sepedi; Northern Sotho
ISO 639-3: Northern Sotho/Pedi/Sepedi
Northern Sotho(?) Sepedi nso nso
Sheng [a Swahili argot] swa [Swahili]
South Ndebele R. does not distinguish
btwn N. & S. Ndebele
isiNdebele nbl nbl
Southern Sotho Southern Sotho; Sesotho Sesotho sot sot
Standard Moroccan Tamazight Tamazight Tamazight zgh zgh
Teso Teso Teso ssa [Nilo-Saharan languages] teo
Tigre Tigre Tigre tig tig
Tigrinya Tigrinya Tigrinya tir tir
Tsonga Tsonga XiTsonga tso tso
Tswana Tswana Setswana tsn tsn
ISO 639-2: Wolof
ISO 639-3: Gambian Wolof
Wolof Wolof wol wof
Zulu Zulu IsiZulu zul zul

Thanks for digging! I'll start working on adding the ISO 639-2 languages. In the meantime, I'll ask Linguist to stop by. Hopefully he can shed some light on the languages (dialects?) that are not in ISO 639-2. Ahasuerus 15:57, 9 September 2018 (EDT)

(unindent) Okay, so this is what I managed to find. The following ISO 639-3 tongues are entered as “languages” in the Greenberg (G) and Ruhlen (R) classifications (sources : Joseph H. Greenberg, Studies in African Linguistic Classification, Compass, Bradford, CT, 1955, 116 p.; Merritt Ruhlen, A Guide to the World’s Languages, Stanford University Press, Stanford, CA, 1991, 9th printing, 463 p.). I’m following the order of the chart above. The spelling is the one used in these sources.

  • Acholi (G, R).
  • Adhola (R).
  • Ebira (R).
  • Gusii (R).
  • Ibibio (R).
  • Igala (R).
  • Kipsikiis (R).
  • Logoli (R).
  • Mandinka (R) / Mandingo (G).
  • Markweta (R).
  • Meru (R).
  • Mixtec (R).
  • Oriya (R).
  • Teso (R).

Not recorded are :

  • Bukusu / Lubukusu.
  • Chiga / Rukiga.
  • Giryama / Kigiryama.
  • Idakho-Isukha-Tiriki / Luidakho-Luisukha-Lutirichi / Lwisukha-Lwidakho.
  • Lugbara / Lugbarati.
  • Mauritian Creole / Kreol Morisien.
  • Nigerian Fulfulde / Fombina.
  • Nigerian Pidgin / Naija Languej.
  • Northern Dagara / Dagaare.
  • Sheng.

In that lot, Mauritian Creole / Kreol Morisien is a variant of Réunion Creole, itself a variety of French Creole, which has a “language” status (not in the db, as far as I know; might be useful, as there is some literature in that language (there are “Tintin” and “Astérix” albums in Réunion Creole). Nigerian Fulfulde / Fombina is a Fulani dialect. As far as Nigerian Pidgin / Naija Languej is concerned, English Pidgin seems to be missing in the db, and there could easily be room for a general "English Pidgins". Northern Dagara / Dagaare is a Dagara dialect. Sheng must be assimilated to Swahili (a slang is not a language in its own right). I'll have to dig a bit more to have a clear view of the remaining five. Linguist 10:54, 11 September 2018 (EDT).

Thanks for looking into this! Ahasuerus 12:23, 11 September 2018 (EDT)
It would sure be nice if ISO had a code covering all 3 Dagaare languages but it doesn't. If we want to add Dagaare at all we'll have to add 3 codes which could be called something like "Dagaare (Northern)," "Dagaare (Southern)" and "Dagaare Dioula." The thing is that ISO 369-3 is a work in progress. We might just have to commit to keeping an eye on it and adjusting our list when we can, if for example they add a macrolanguage code for Dagaare. --Vasha (cazadora de tildes) 12:19, 11 September 2018 (EDT)

Language names

P.S. We'll also need to decide which names we want to use. Some ISO names, e.g. "Northern Sotho/Pedi/Sepedi", are on the long side. Ahasuerus 16:07, 9 September 2018 (EDT)

As far as language denominations are concerned, as we are an English-language db, we'd better stick to the usual English names of the ISO 639-2-recognized languages in question, and forget about local usage. After all, we don't use français for French or deutsch for German. As for the language / dialect distinction, for many reasons, linguists usually consider this a highly subjective point of view, with strong political and nationalistic overtones (e.g. Galician is historically a variety of Portuguese, but has long been included in Spanish dialects, etc.). Linguist 09:29, 10 September 2018 (EDT).
That was one of the reasons why we farmed it out to ISO 639-2 in the first place :) Ahasuerus 11:25, 10 September 2018 (EDT)
I'll do what I can with the ISO 639-3 African languages, but I need to check a few things first. I'll keep you informed… :o). Linguist 09:29, 10 September 2018 (EDT).
Re: the issue of naming, I agree that we want to use their English names, but the problem is that sometimes the ISO standard lists multiple alternative names. For example, take Asturian. The 639-2 standard calls it "Asturian; Bable; Leonese; Asturleonese". After some hesitation, we decided to call it "Asturian/Bable". I wonder if it would be feasible to do similar pruning with certain ISO language names like "Northern Sotho/Pedi/Sepedi". Ahasuerus 11:25, 10 September 2018 (EDT)
It may be best not to use the ISO standard as the source of names since their practices may differ from familiar colloquial names for the language. The Sotho languages are a good example; I've been doing some Internet searching and what I find is that absolutely no one uses the names Northern Sotho and Southern Sotho except linguists. The official South Africa names are Sepedi and Sotho; colloquial practice is to call the first Sepedi and the second either Sesotho or Sotho. I think we should not use linguists' names here; experts are capable of finding variant names. So my suggestion for our two names would be "Sepedi" and "Sesotho/Sotho." --Vasha (cazadora de tildes) 04:43, 11 September 2018 (EDT)
The problem with abandoning one part of the ISO standard is that we may be opening cans of worms that we are not even aware of. Country/language names can be controversial, e.g. "Ukraine" vs. "the Ukraine" before the name was officially changed. Who knows what kind of baggage the names of less popular languages may carry? By using an international standard approved and maintained by a third party, we avoid all of these issues. Ahasuerus 11:00, 11 September 2018 (EDT)
We do casual searchers a disservice by using ISO names that they're not familiar with, and being able to say "If we used a wrong name, blame ISO not us" is not sufficient justification. The task of researching what native speakers call their language when speaking English, while difficult, is not impossible, I think. --Vasha (cazadora de tildes) 12:28, 11 September 2018 (EDT)
It may be possible, but I don't think it would help us. As discussed earlier, we use English names as opposed to français, deutsch, nederlands, srpski, polski, nihongo, etc. Ahasuerus 12:52, 11 September 2018 (EDT)
P.S. Sorry, I missed the "when speaking English" part. Ahasuerus 13:09, 11 September 2018 (EDT)
Easier is simply finding out the most widespread appellation. --Vasha (cazadora de tildes) 12:28, 11 September 2018 (EDT)
The issue here is that the "most widespread appellation" may be different depending on the period, the region and the subset of literature that you check. The Ukrainian controversy that I mentioned earlier is a perfect example: prior to 1991 you would have gotten different results depending on which books you had access to. Historians had to add notes explaining why they went with one usage or the other. Etc.
It was exactly what we were trying to sidestep when we decided to farm these decisions out to a professional organization like ISO -- they are vastly better qualified to make these types of decisions than we will ever be. I can see us using another third party source (like the ones consulted by Linguist yesterday), but I believe that it would need to be an established professional/neutral source at the level of ISO as opposed to our own research. Ahasuerus 13:08, 11 September 2018 (EDT)
A good idea in principle, but ISO ISO is not user-friendly for laypeople. Isn't there a better third parry to call on? (Wikipedia?) --Vasha (cazadora de tildes) 14:23, 11 September 2018 (EDT)
I think ISO 639-2, which covers major languages, has served us well overall. ISO 639-3, which was expanded to cover less popular languages and dialects, may be more problematic. Unfortunately, I don't know enough about the field to suggest other sources which we may be able to use either as an alternative to ISO 639-3 or in conjunction with it. Perhaps we can use Merritt Ruhlen's 1991 A Guide to the World’s Languages -- see Linguist's post below -- to define the subset of ISO 639-3 languages which we want to support.
Wikipedia, alas, is too transient for our purposes. Back when it became big (ca. 2005-2006), Al and I thought that we could move certain types of ISFDB data there and then link to it. That's why the original ISFDB 2.0 design supported only one Web page per record and it was reserved for Wikipedia URLs. Unfortunately, after writing lots of SF and other articles for Wikipedia, I realized that Wikipedia was unlikely to become as reliable or as permanent as we had hoped. That's when I converted the "Wikipedia URL" field to a "multi-field" for third party Web pages and Wikipedia lost its privileged position. Ahasuerus 15:03, 11 September 2018 (EDT)

(unindent) Would you suggest that we use Greenberg and/or Ruhlen as the guide when deciding which ISO 639-3 languages to include? I suppose Ruhlen would be a better choice because it covers the whole planet and because it's much more recent. Also, have there been updates since 1991? I am thinking of things like the official split of the "Serbo-Croatian" language into Serbian and Croatian, which was reflected in ISO 639-2 (and consequently in our software.) Are there similar issues with ISO 639-3-only languages which have arisen since 1991? If there are, we'll need a way to handle them. Ahasuerus 12:23, 11 September 2018 (EDT)

Yes, I think following Ruhlen would be a good choice — although of course he is not the only reference in that matter, but he is one of the most recent ones. As far as I know, there have been reprints but no new editions of his Guide to the World’s Languages (contrary to his Guide to the Languages of the World, 1975, new expanded edition 2005, but mainly concerned with phonological systems). I can't think of any major issues with ISO 639-3-only languages at the moment, but if I come across them I'll let you know. Linguist 11:18, 12 September 2018 (EDT).
Thanks! Re: creoles and pidgins, ISO 639-2 has a special code, "crp", explicitly for "Creoles and pidgins". Would it be helpful to add it? Ahasuerus 21:54, 12 September 2018 (EDT)
Personally, I find it a bit too general. Would it be possible to have something like English-based Pidgin, French-based Creole, etc. ? To be created as you need them, not to clutter up the list too much… Linguist 08:01, 13 September 2018 (EDT).
It turns out that ISO 639-2 has separate codes for "Creoles and pidgins, English based", "Creoles and pidgins, French-based", and "Creoles and pidgins, Portuguese-based" as well as a cat-all code for "Creoles and pidgins". Problem solved! :-) Ahasuerus 20:54, 18 September 2018 (EDT)
One problem is that the debate as to whether Nigerian Pidgin is a pidgin or a creole is currently unresolved. --Vasha (cazadora de tildes) 12:20, 13 September 2018 (EDT)

ISO 639-2 vs. ISO 639-3 vs. Other Nomenclatures

Re: ISO 639-2 vs. ISO 639-3, it's a thorny issue. ISO 639-2, which we currently use, may have become too restrictive now that we are beginning to enter less well-known languages. For example, ISO 639-2 has individual codes for some more popular Bantu languages, but the rest are covered by "bnt", a catch-all code for all Bantu languages and dialects. That doesn't given us enough granularity when trying to enter an anthology of stories written in different Bantu languages.

On the other hand, ISO 639-3 may have more granularity than we need. For example, it states that Albanian is a macrolanguage and lists 4 "individual languages" under it: "Arbëreshë Albanian", "Arvanitika Albanian", "Gheg Albanian" and "Tosk Albanian". I am sure it's a useful distinction when dealing with the spoken language, but not one that we would want to use for bibliographic purposes since, as far as I know, the written language is just "Albanian".

So... If ISO 639-2 is "too little" and ISO 639-3 is "too much", what should we do? I guess what we are after is the "literary" subset of ISO 639-3 codes. Does such a thing exist? Ahasuerus 11:25, 10 September 2018 (EDT)

I am coming around to thinking that it might be OK to stick with using ISO 369-2 on condition that:
  1. we identify some groups of languages that can be covered by a common ISO 369-2 code, and use Ruhlen's name for the group, with details of the exact language to be given in the title notes;
  2. we use Ruhlen's names for individual languages that have ISO 369-2 codes;
  3. we add a category "Other" (or "Other [see notes]") for languages that aren't accommodated by either of these.
The upside is a shorter, simpler list of languages; the downside is that someone who (for example) wonders whether any speculative literature has been published in Mixtec would have to search the notes rather than the list of languages. --Vasha (cazadora de tildes) 13:21, 12 September 2018 (EDT)
"Other" is an interesting idea. It's not explicitly in the ISO 639-2 standard, but ISO 639-2 includes a range of codes (qaa-qtz) which are officially "reserved for local use". If we add "Other" as a "local use" language, we won't be going against the standard. The only possible caveat that comes to mind is that we will need to decide how to enter certain uncommon dialects. For example, is the famous Cockney rhyming slang "English" or "Other"? Not that I expect many SF stories written using Cockney, but you never know.
Re: the use of Ruhlen's language names, let me make sure that I understand the proposal correctly. Are you suggesting that when ISO 639-2 and Ruhlen's book use different language names, we should use Ruhlen's name instead of what's listed by ISO 639-2?
If so, how about a compromise: we take the ISO 639-2 name as well as Ruhlen's name and create a composite name like "Asturian/Bable" or "Pashto/Pushto"? Ahasuerus 22:25, 12 September 2018 (EDT)
I guess it does no harm to put a long string of alternate names in the list. The important thing would be to put the most familiar-to-laypeople name first, for the sake of people who are using the list by scrolling rather than typing. --Vasha (cazadora de tildes) 22:46, 12 September 2018 (EDT)
I can think of three categories of users who would be affected by the displayed order of language names:
  1. Users who view titles
  2. Users who select languages in Advanced Search
  3. Editors who edit data
For the first category of users, the order of language names shouldn't matter much because all of them would be displayed on the same line. For the second category of users, the impact would be more significant. For the third category of users, I suspect that the impact may be less significant than in the second case because data entry work is more time-consuming than casual searching, so editors become more accustomed to the way the software works. Am I missing any other categories? Ahasuerus 13:16, 13 September 2018 (EDT)
We could also enhance the drop-down lists to search for any string contained in the list, not just the first few letters. Ahasuerus 22:25, 12 September 2018 (EDT)
I'm not sure about your proposed modification to the typing; wouldn't it throw people off to type "fr" like they're accustomed to and instead of the French they want, get Afrikaans? --Vasha (cazadora de tildes) 22:46, 12 September 2018 (EDT)
That's a good point. I failed to consider the side effects. I wonder if there may be another way to allow searching for language names without affecting the established process. Ahasuerus 12:55, 13 September 2018 (EDT)
Have advanced search be free text rather than the list; keep established behavior otherwise. --Vasha (cazadora de tildes) 13:56, 13 September 2018 (EDT)
An interesting thought. I can see how it could be useful even when looking for certain languages that we currently support, e.g. Serbo-Croatian/Serbian/Croatian and the three forms of Norwegian.
On the other hand, it's handy to be able to scroll through the list of supported languages, which can serve as a discovery tool: "Oh, there is SF written in Ancient Greek and Latin? Let me see..." It can also help with pesky spelling problems, e.g. is Yiddish spelled "Yiddish" or "Yidish" in English?
So how about we try to have our cake and eat it too? Instead of changing the current Advanced Search option why don't we rename it to something like "Language (list)" and add a new option to the left column, "Language (free form)"? Ahasuerus 16:02, 13 September 2018 (EDT)

Handling Languages in the Software

Just a thought here: How many stories will we have from these languages? Adding them is all good and nice until you need to work with that list and it takes 2 minutes to get to the language you need. If we are going to keep adding languages, we need the ability to have "shorter" list in some way or form (globally or as a profile setting)...Annie 18:11, 9 September 2018 (EDT)

I like this idea. If there was a way to "subscribe" to languages, perhaps they could be listed at the top of the drop-down, before all the other languages (as a user setting). ···日本穣 · 投稿 · Talk to Nihonjoe 18:26, 9 September 2018 (EDT)
Nihonjoe's idea isn't a bad one. On the other hand, I could envision where a pulldown menu has a short(ish) list and the last first item on the list is "show extended list" which, when clicked, expands the rest. (ETA: I don't think this works; more pondering needed.) Here's the languages which we currently have at least 40 titles in, with parentheses marking ones which would be excluded by a cutoff at 50 titles: (Ancient Greek), (Arabic), Bulgarian, Catalan, Chinese, Croatian, Czech, Danish, Dutch, Esperanto, Finnish, French, German, Greek, (Hebrew), Hungarian, (Icelandic), (Irish), Italian, Japanese, Korean, Latin, Lithuanian, Norwegian-Bokmal, Polish, Portuguese, Romanian, Russian, Serbian, Slovenian, Spanish, Swedish, Turkish, Yiddish. --Vasha (cazadora de tildes) 19:00, 9 September 2018 (EDT)
When I pull up the language list, I simply type "fr" for French, "ger" for German, etc, which lets me jump to the right language almost instantly. Do other editors use different methods? Ahasuerus 19:18, 9 September 2018 (EDT)
I do that too on a laptop/desktop. Unfortunately, it isn't possible on a mobile interface. --Vasha (cazadora de tildes) 19:23, 9 September 2018 (EDT)
Oh, mobile devices. I see. Ahasuerus 20:53, 9 September 2018 (EDT)
It occurs to me, also, that language is one thing that casual searchers are likely to want to search by. A solution to make the list more manageable for them shouldn't depend on user preferences. --Vasha (cazadora de tildes) 19:38, 9 September 2018 (EDT)

(unindent) I wonder if the ideal solution may not be some kind of combination of the two proposed approaches. Something like:

  • Create a nightly process to identify the top 10 most popular languages
  • Change the drop-down lists of languages to display an alphabetized listing of the "top 10" at the beginning of the list (make sure that it is displayed as a separate sub-section)
  • Let users override the "top 10" list with whatever they want

It wouldn't be hard to do conceptually, just somewhat time-consuming to implement. Ahasuerus 22:25, 9 September 2018 (EDT)

The top 7 would be sufficient; there is a pretty obvious gap between them and the rest. --Vasha (cazadora de tildes) 18:02, 13 September 2018 (EDT)

"Other" vs. ISO 639-2 language groups

Re: the issue of non-ISO 639-2 languages, the use of "other" has been suggested. However, as we discussed earlier, it would cover a lot of different unrelated languages.

After sleeping on it, I think we may be better off using ISO 639-2-supported language groups whenever possible. For example, the Teso (Ateso) language doesn't have an ISO 639-2 code, but ISO 639-2 has a code for "Nilo-Saharan languages" languages. Similarly, ISO 639-2 doesn't have a code for the Chiga/Rukiga/Kiga language, but it has a code for "Bantu languages". Etc.

It seems like it would give us a lot more granularity than "other" and would make our users' life easier. Ahasuerus 20:06, 14 September 2018 (EDT)

Yeah, not a bad idea. I hope it'll be possible to find suitable super-categories for all the languages we need. On a more detail-oriented note, I think the entry in the list should be "Bantu language" or "Nilo-Saharan language," with the capitalization as shown so as to indicate that this is not the name of an individual language. --Vasha (cazadora de tildes) 20:35, 14 September 2018 (EDT)

Trying to Formulate Tentative Consensus

Re-reading the discussion above, I think we are getting close to something approximating a tentative consensus re: a few issues. Here is what I think we can agree on at this point:

  • In Advanced Title Search and Advanced Author Search, rename the "Title/Working Language" field to "Title/Working Language (list)". Add a new option, "Title/Working Language (free form)".
  • For ISO 639-2 languages, check Merritt Ruhlen's A Guide to the World’s Languages (Stanford University Press, Stanford, CA, 1991, 9th printing) to see if the latter uses a different language name. If it does, append add it to the ISO 639-2 language name.

Does this look right? Ahasuerus 20:06, 14 September 2018 (EDT)

You mean "add it to ..." instead of "append it to ..." right? :-) We are still arguing the issue of how to determine which name goes first --Vasha (cazadora de tildes) 20:12, 14 September 2018 (EDT)
Sorry, I thought the issue lost its relevance when the Advanced Search change was proposed. Let me change "append" to "add" to leave it open-ended. Ahasuerus 23:37, 14 September 2018 (EDT)
Well, the proposal is to have a list in Advanced Search as well as freeform search. So, if one name for a language is used significantly more often than others, putting it first maximizes the chance of someone scrolling down the list spotting what they're looking for. --Vasha (cazadora de tildes) 12:11, 15 September 2018 (EDT)

(unindent) I haven't forgotten about this issue. I am currently working on something else and hope to wrap it up in the next day or two. I will then revisit this area. Ahasuerus 10:46, 16 September 2018 (EDT)

The table has been updated with Ruhlen's names and ISO 639-2 codes for language families. I have asked Linguist to review the results to make sure that I didn't mess up any assignments.
Assuming there are no changes, there is only one ISO 639-2 language whose ISO 639-2 name differs from the name used by Ruhlen: "Acoli" (ISO 639-2) vs. "Acholi" (Ruhlen). Given that it's just one language and that the difference is minor and doens't affect sorting, I don't think adding Ruhlen to our mix of standards would be worth it. Ahasuerus 21:11, 18 September 2018 (EDT)
I have added some more info to the table. I found that Mandinka does indeed have an ISO 639-2 code "man" (under the less-used name Mandingo), and also I found some codes where we'll need to make choices about what names to use in what order:
  1. Minor differences: ach (Acoli, Acholi); ful (Fulah, Fula)
  2. Greater differences: kin (Kinyarwanda, Rwanda); lug (Lugbara, Logbara); luo (Luo, Dholuo)
  3. Potentially especially confusing: sot (Southern Sotho, Sotho, Sesotho); nso (Northern Sotho, Sepedi, Pedi). Also nde & nbl (North[ern] and South[ern] Ndebele) since they are not necessarily distinguished from one another; according to Ethnologue they use the same autonym.
In the second and third groups, further research into colloquial and official names is required. --Vasha (cazadora de tildes) 20:30, 20 September 2018 (EDT)
Thanks for digging! While we are waiting for Linguist to review the findings, I plan to go ahead and add the ISO 639-2 languages which do not have a conflict. I can't think of any reason to keep Kurdish or "Creoles and pidgins, French-based" out while we are sorting out various versions of Sotho, Ndebele, etc. Ahasuerus 13:16, 24 September 2018 (EDT)
ISO Code Names with Approximate GHits Suggested Name
ach Acoli Acholi Acholi
30 1700
ful Fulah Fula Fula
50 11,000
kam Kamba Kikamba Kikamba (text searches
for Kamba will find this)
450 400
kik Kikuyu Gikuyu Kikuyu/Gikuyu
17,500 800
kin Kinyarwanda Rwanda Kinyarwanda
18,000 3,000
lug Ganda Luganda Luganda
250 17,000
luo Luo Dholuo Luo/Dholuo
8,600 3,400
man Mandingo Mandinka Mandinka/Mandingo
1,700 2,900
nso Northern Sotho Pedi Sepedi Sepedi/Northern Sotho
4,200 250 38,000
ori Oriya Odia Odia/Oriya
33,000 51,000
sot Southern Sotho Sotho Sesotho Sesotho/Southern Sotho
800 10,600 30,000

Also, I suggest that the best way of resolving the Ndebele problem might be nde = "Ndebele, Northern (Zimbabwe)"; nbl = "Ndebele, Southern (South Africa)" --Vasha (cazadora de tildes) 20:00, 28 September 2018 (EDT)

As I mentioned earlier, I am not a fan of using internet search results for these purposes. Country/language names can have a ton of baggage which we may not be familiar with and are certainly not in a position to take a stand on -- see "Kampuchea/Cambodia", "Ukraine/the Ukraine", "Serbian and Croatian vs. Serbo-Croatian" pre-1991, etc. I can see us changing our standard to allow appending names used by a reputable third party, but not the internet. Ahasuerus 19:01, 29 September 2018 (EDT)
Did you have a chance to check out the results of my internet rsearch above? Mostly the results don't conflict with ISO-approved names, they only tell us which order we should list the names in. (And if you insist on using ISO's spelling "Fulah" in spite of the fact that absolutely no one else does, no real harm done.) There is, however, one real problem, namely Ganda/Luganda. The ISO-aproved name "Ganda" comes up only 250 times in searches for everyday uses verses 17 thousand hits for "Luganda." If we listed only the ISO name "Ganda", people looking for "Luganda" would not be able to find it either in the alphabetical list or by text searching. Seems like we absolutely must disagree with ISO here. --Vasha (cazadora de tildes) 19:04, 29 September 2018 (EDT)
Yes, I was responding above while you were writing this comment.
I should probably add that my concern is not purely hypothetical. A few years ago a new editor joined and wanted to eliminate a certain language. A bit later another editor joined and began using that very language, so there was clear potential for conflict. At the time we were able to avoid the problem by pointing out that the language was a part of ISO 639-2. That was a very convincing argument in favor of sticking to ISO 639-2 as much as possible.
In any event, the good news is that the experiment with changing "Mayan languages" to "Mayan language" was a success. Back when languages were added, I didn't consider the possibility that language names may need to be changed, so the software wasn't designed to support the functionality. Now that we know that it can be done and that the only downside is that old submissions will continue to display the old language name, it makes things much easier. We can add the ISO 639-2 names to the system, enter the titles that require them and then debate whether we want to change our standard for language names. Ahasuerus 13:28, 30 September 2018 (EDT)
I do not mean search results to be authoritative, only to give hints as to how to most helpfully use names. And for matters that will hardly affect user experience, such as the spelling of Acholi/Acoli, I have no problem going with ISO. But this quick search does flag up some issues that deserve to be further examined.
Almost all of the names I searched are used in ISO 369-3. You do not object to adding ISO 369-3's "Mandinka" to ISO 369-2's "Mandingo," do you? Ditto for "Dholuo" and "Odia." As I said, in most cases I want to use these search results as a hint of what order to put the names in -- it is useful information when there is a very glaring difference between the two names. And the results for Luganda ("Ganda" used only 1.5% of the time!) tells us that yes, we need to look to another source there. (Ruhlen uses "Luganda.") --Vasha (cazadora de tildes) 15:42, 30 September 2018 (EDT)
The problem with using ISO 639-3 names is that some of them may describe different languages. For example, the "Oriya" recognized by ISO 639-2 (ISO code "ori") is a macrolanguage; ISO 639-3 calls it "Oriya (macrolanguage)". On the other hand, "Odia/Oriya" (ISO code "ory"), which is recognized by ISO 639-3 but not by ISO 639-2, is an individual language. That's why ISO 639-3 calls it "Odia, Oriya (individual language)". So if we were to add "Odia" to the name "Oriya", we would be effectively adding a language not recognized by ISO 639-2. It's a jungle out there... Ahasuerus 19:17, 1 October 2018 (EDT)
Yes, I see. And I now notice that Mandingo (man) according to Ethnologue is a macrolanguage which includes Mandinka (mnk). Ugh. Well, I guess this isn't all that different from using names of language groups--you just have to explain in notes exactly what language is meant. At least Dholuo is a genuine alternate name of Luo according to Ethnologue; could we call that one "Luo/Dholuo" so that if anyone searches for "Dholuo" they can find it? And Ethnologue prefers the name Ganda but does admit luGanda (capitalized thus) as a genuine alternate name. --Vasha (cazadora de tildes) 19:37, 1 October 2018 (EDT)

Statistical reports migrated to the nightly job

The process of generating ISFDB Statistics and Top Lists has been migrated to the nightly job, which should improve performance. No more waiting 5 seconds for the software to generate a list of the Highest Ranked Titles of All Time etc. A few reports may still take a second or so to compile, but overall performance should be much better than under the old system.

As a general observation, it's unfortunate that performance tweaks consume valuable development man-hours. However, it's an inevitable side effect of database growth: the same reports that took a second to compile in 2012 may take up to 5 seconds to compile in 2018 because we have many more records on file: 54,775 awards, 1,519,153 titles and so on. It requires rethinking and rewriting certain parts of our software which I'd much rather leave alone, but c'est la vie. Ahasuerus 17:01, 11 September 2018 (EDT) ASINs

I just entered this one. It's an audiobook on Using the Audible ASIN opton doesn't work because it defaults to the US store. Do we want to add support for They don't have much there yet, but it seems to be growing. Here's the SF/Fantasy category. ···日本穣 · 投稿 · Talk to Nihonjoe 20:24, 11 September 2018 (EDT)

Let's think about it. Regular ASINs are supposed to be unique across all Amazon stores. For example, the ASIN of this publication is B00TONTAEQ. Our publication record displays ASIN-based links to the 14 supported Amazon stores. With one exception (not available in Canada for some reason) they all take you to the right ebook at the right store.
Are Audible ASINs also unique across all Amazon stores? If they are, I can easily make Audible ASINs behave like regular ASINs and display links to the supported Amazon stores. Ahasuerus 21:10, 11 September 2018 (EDT)
I'm pretty sure they are. They just don't show up in the US Audible store when you go there. Now we just need a list of all the Audible stores. ···日本穣 · 投稿 · Talk to Nihonjoe 21:17, 11 September 2018 (EDT)
It would be nice to review an example of an Audible ASIN being used across multiple Audible stores. As I recall, Annie worked on Audible books at one point. Perhaps she may have additional insight into this issue. Ahasuerus 22:41, 11 September 2018 (EDT)
I doubt that there will a lot of cross publication between Japanese and English titles but the US store had been adding some more international titles lately so I willl see if I can figure out something when I get to a real computer tomorrow. From what I saw on the Japanese site, these look like regular B ASINs which Amazon has only one data add of. But will do some more digging and checking to see if I can spot a ASIN used at 2 ormore audible sites. Annie 01:05, 12 September 2018 (EDT)

Third party URL validation tweaked

Third party URL validation has been further tweaked. In addition to angle brackets, spaces and double quotes are no longer allowed. There are a few dozen bad URLs in the database (some are not clickable), which I will be fixing manually. Ahasuerus 17:46, 12 September 2018 (EDT)

Done. Ahasuerus 15:10, 13 September 2018 (EDT)

Cover art field in publication view

I just noticed: There is now no need to have the label "Cover" be a link to the cover art record in publication view, since we changed to having the title displayed there --Vasha (cazadora de tildes) 05:47, 13 September 2018 (EDT)

Well spotted. Fixed. Ahasuerus 15:48, 13 September 2018 (EDT)

External ID cleanup and validation

Earlier today I discovered that the External ID field was used incorrectly in certain cases. Some editors occasionally added parenthetical notes, which broke automatically generated links to third party sites. There were also pubs with cover artists, authors or series names in the External ID field, apparently due to data entry errors.

I have cleaned up the data and updated the software to disallow the same set of invalid characters that is currently disallowed for third party URLs: spaces, double quotes and angle brackets. The software changes were a bit trickier than I originally expected; if you come across anything unexpected, please let me know. Ahasuerus 18:51, 14 September 2018 (EDT)

Expand the "Tr" template with an author ID so that it can create a link to existing author records

I've been going through some title records which don't contain the {{Tr}} template, but do contain "Translated by X" text in the note, in order to replace it with the "Tr" template. It looks like many of these translator information have been entered with a link (<a href tag) around the translator's name if the translator already has an author record in the database (example). The only way to keep the link is either to put the "Tr" template inside the a href tag (example), or to include the complete a href tag inside the "Tr" parameter. I think we could make adding the link manually superfluous because the template itself could create the link: the software could add the possibility to additionally state the author id, for example in this way: {{Tr|X|id}}. This would also show "Translated by X", but the "X" would be a link to the author record of the provided id. Jens Hitspacebar 10:57, 16 September 2018 (EDT)

Adding record IDs to templates (any templates, really) would not be safe since our IDs are not guaranteed to be stable.
However, since the "A" template already links to author records based on the entered name, it would be easy to modify the "Tr" template to do the same thing. We'll just have to flesh out the error message which the Summary page displays. Instead of "Author not found: [name]" it could say something like "No works attributed to [name] on file". Ahasuerus 11:33, 16 September 2018 (EDT)
Hm, good point. Your suggestion would always add a link, if I've understood it correctly. I'm not sure if that's a desirable feature, considering that many translators don't have an author record in the database yet, and also considering that the parameter in the "Tr" template has been used for multiple translators in forms like "{{Tr|Translator 1, Translator 2 and Translator 3}}" already. Always having a link would probably create more "Not found" events for users than leading them to a real author record. Reconsidering all this I think the small benefit of such a feature is not worthwhile the hassle it may bring, and I rather withdraw my suggestion :) Jens Hitspacebar 12:28, 16 September 2018 (EDT)
Thinking some more about it, it occurs to me that we could create a new, linking, template for translators who are also authors. It would be easy to implement, although I am not sure how useful it would be. Ahasuerus 12:48, 16 September 2018 (EDT)
Assuming you can't embed templates e.g. "{{Tr|{{A|Translator}}}}", we could put "{{Tr|Translator}} (see {{A|Translator}}}". ../Doug H 13:30, 16 September 2018 (EDT)
A new, linking template would work, but then we'd have two similar templates to teach to editors and to keep track of in software and wiki changes. Not sure if it's worth the effort. Though I'd use it if it existed. :) Jens Hitspacebar 13:43, 16 September 2018 (EDT)
Then there's the issue of variant names. Some translations by authors who have records in this database are credited using names or forms thereof that we do not have pseudonym records for. So they wouldn't link correctly. Plus, translations credited to names that are disambiguated surely haven't been correctly dealt with. So yeah, we would need a new template rather than changing the old one, and it would have to have some way of both indicating how the translator is credited in the book, and what their canonical name is. It'd be nice to have the info available when we finally have a real translator solution in place, but I'm not sure it's worth putting a lot of work into at this stage. --Vasha (cazadora de tildes) 18:41, 16 September 2018 (EDT)

New cleanup report -- anthologies and collections without fiction titles

A new cleanup report, Anthologies and Collections without Fiction Titles, has been deployed. The data will become available tomorrow morning. Here is how FR 1164 describes the new functionality:

  • Create a cleanup report to find anthology and collection publications with no fiction titles. It should consist of 2 Web pages.
  • The first Web page will contain 2 tables. The first table will show counts of empty pubs per year and per month since 2000. The second table will show counts of empty pubs per decade and per year prior to 2000. Each count will be a link to the second Web page, which will display a standard table of eligible pubs. The first page will also contain a separate link for 0000-00-00 pubs.
  • The second Web page will display each empty pub's title, author, date, title type and note. Moderators will be able to ignore pubs.

Once we confirm that everything is working as intended and that the design is solid, we can create a similar report for magazines and fanzines. At some point, once the cleanup process has reached the point of diminishing returns, we can change these reports to include publications with only one fiction title. Ahasuerus 13:41, 17 September 2018 (EDT)

The following changes have been made to the second page of the cleanup report:
  • The "Pub. Type" is now called "Type". Its values are displayed as "COLL" and "ANTH".
  • A new column, "Publisher", has been added.
  • A new column, "1st Edition", has been added. It displays the date of the container title if it differs from the date of the publication.
Ahasuerus 16:30, 24 September 2018 (EDT)
I like it. The inclusion of the 1st edition column + the Notes really helps for spotting ones I want to fill in. (Yeah, yeah, they should all be filled in, but be real, there aren't three of me.) --Vasha (cazadora de tildes) 17:11, 24 September 2018 (EDT)
Thanks for working on these issues! Ahasuerus 18:11, 24 September 2018 (EDT)

Advanced Search - free-form language searches

Advanced Title Search and Advanced Author Search have been enhanced. You can now choose either "[Title/Working] Language (list)" or "[Title/Working] Language (free form)" from the drop-down list. The "(list)" version supports the same functionality as the previous language search version. The "(free form)" version lets you enter an arbitrary string of characters in the search value field. Ahasuerus 12:25, 18 September 2018 (EDT)

Pauline Morgan canonical name

This author uses the name Pauline Morgan for all of her editorial and reviewing work, and the name Pauline E. Dungate for all of her fiction. Is there some reason why we have Morgan as the canonical name? Wouldn't it be more usual to go with the one she uses for fiction writing instead? --Vasha (cazadora de tildes) 06:02, 21 September 2018 (EDT)

Do you know the author's legal name? In cases like this for me it seems most rewarding to use the legal name as canonical (so we would show the pseudonym as pseudonym, and not the legal name; however, there are many cases where the pseudonym is used far more exceedingly for the majority of an author's work). Stonecreek 08:29, 21 September 2018 (EDT)
Well, the standard is the most recognized name for that author within the genre, so I guess it depends on whether the person is primarily an editor/reviewer or a fiction author. In this case I'd say that she is primarily a fiction author. Moreover, she's been more active as "Pauline E. Dungate" over the last 20 years, so I would be in favor of changing the canonical name to Dungate. Ahasuerus 11:18, 21 September 2018 (EDT)
I think (not entirely sure) that Morgan is her legal name; under that name she's been pretty active in literary and fannish organizations. However, a Google search shows quite a lot of web presence as Dungate too, including interviews and so forth. I agree with changing the canonical name. --Vasha (cazadora de tildes) 16:22, 21 September 2018 (EDT)

O. M. Grey canonical name

Here's an obvious one: Christine Rose's canonical name should clearly be changed to O. M. Grey. If no one objects, I'll do that tomorrow. --Vasha (cazadora de tildes) 16:25, 21 September 2018 (EDT)

"Diff Publications" renamed

The option previously known as "Diff Publications" is now called "Compare Publications". Ahasuerus 10:06, 22 September 2018 (EDT)

Changes to the way submitted Notes/Synopses are displayed

The way submitted notes and synopses are displayed on post-submission/moderator approval Web pages has been changed. For changed notes/synopses a summary of the change is displayed in the Warnings column. Modified, deleted and added lines are displayed with a leading "-" or "+" sign as appropriate. The changed data is displayed "raw", without HTML formatting, in order to make it easier to spot subtle differences.

The new functionality is rather rudimentary, but hopefully it's better than the old way, which often involved staring at multiple lines of near-identical text and trying to figure out what has been changed. Ahasuerus 20:27, 23 September 2018 (EDT)

Fantastic, many thanks! That's very helpful and will save lots of time. Jens Hitspacebar 13:35, 24 September 2018 (EDT)
I knew I wasn't the only one who couldn't do "diff" as fast as a computer! (Fixer tells me that it's only to be expected from carbon-based lifeforms, but he won't hold it against us.) Ahasuerus 14:21, 24 September 2018 (EDT)

Claire Delacroix vs. Deborah Cooke

Back in 2008 Deborah Cooke had two series launched. The first one, Dragonfire, was published by Signet and used her legal name. The second one, Prometheus Project, was published by Tor and used "Claire Delacroix". At the time we decided to go with "Claire Delacroix" as her canonical name, probably because she had also had a few novellas published under that name.

As of 2018 she has had a lot more books published as "Deborah Cooke" than as "Claire Delacroix". She still occasionally publishes new works as Delacroix (e.g. this 2018 novel), but "Deborah Cooke" is clearly the primary name. Even her Tor books have been reprinted as by Cooke. Calling for volunteers who would be willing to work on reversing the canonical name/pseudonym relationship. Ahasuerus 14:33, 24 September 2018 (EDT)

I will do that just as soon as I finish with Pauline E. Dungate! --Vasha (cazadora de tildes) 17:44, 24 September 2018 (EDT)
Thanks! Ahasuerus 17:49, 24 September 2018 (EDT)
There's three names involved here, when do I get the third part?--Dirk P Broer 19:39, 24 September 2018 (EDT)
Which one is the third one? Claire Cross, the pseudonym which she used in the 1990s? It looks like it has already been re-pointed to Deborah Cooke. Ahasuerus 20:08, 24 September 2018 (EDT)
I think it is all correct now --Vasha (cazadora de tildes) 21:07, 24 September 2018 (EDT)
A couple of dates had to be adjusted -- the canonical title uses the date of the variant title if the VT was published first -- but otherwise everything looks good. Thanks for working on this author! Ahasuerus 21:34, 24 September 2018 (EDT)

Position of editing tools in sidebar

I'd like to put this to a vote: Personally, I would like to see Editing Tools moved above Other Sites in the left sidebar, so as not to have to scroll down every time I make a variant, etc. What do other people think? --Vasha (cazadora de tildes) 17:43, 24 September 2018 (EDT)

Well, the original reasons why "Editing Tools" and "Add New Data" are displayed at the bottom of the navigation bar were:
  • separate editing options from other menu options
  • give a higher profile to menu options which non-editors would be accessing
Moving "Editing Tools" up would split the editing options and make it harder for non-editors to get to the "Other Sites" section.
That said, one way to alleviate the need for scrolling would be to convert the main navigation bar sections (Logged In As, Other Pages, Editing Tools, Add New Data) to on-demand drop-down lists similar to the list currently used by "Other Sites". Unfortunately, last I heard, Other Sites were still not working correctly for mobile devices that use iOS.
In addition, at one point I proposed moving the navigation bar from the left side to the top of the page. It would free up a fair amount of real estate, which some of our tables need badly. It would also eliminate the need for scrolling. However, first we need to resolve the iOS issue.
For now, I think I should be able to move "Policies" and "License" to the bottom bar without causing any issues. Ahasuerus 18:10, 24 September 2018 (EDT)
Just confirming that "Other Sites" indeed does not work on IOS/IPhone's Safari (the native browser). If the rest of the menus are converted, the site will be unusable on these devices. :( Annie 20:13, 1 October 2018 (EDT)
Thanks for the confirmation! Some stackexchange discussions seem to suggest that there are ways to get iOS-based browsers to handle this type of menus properly. Would anyone happen to know iOS developers who may know more about this issue? I could experiment on my end, but I don't have an iOS device. Ahasuerus 20:45, 1 October 2018 (EDT)

Language groups/families

As many of you know, our current language policy is to support ISO 639-2-recognized languages. The ISO 639-2 standard has individual codes for popular languages and for some less popular languages. The majority of less popular languages are grouped under language families/groups like "Algonquian languages", "Karen languages", etc.

Following the ISO 639-2 standard, we added "Mayan languages" a couple of years ago. Based on this recent discussion of (mostly) African languages, I am about to add 20 more language codes. 6 of them are language families/groups:

  • Nilo-Saharan languages
  • Bantu languages
  • Niger-Kordofanian languages
  • Central American Indian languages
  • Creoles and pidgins, French-based
  • Creoles and pidgins, English-based

In an earlier comment Vasha suggested that it may be better to display these language groups using the word "language" instead of "languages": "Nilo-Saharan language", "Bantu language", etc.

After thinking about it, I am inclined to go with the "Mayan languages" precedent and use the word "languages". "Creole and pidgin, French-based" seems less clear than "Creoles and pidgins, French-based". Also, the plural form of "Central American Indian languages" etc emphasizes that it's a member of a language group as opposed to some language called "Central American Indian".

Thoughts? Ahasuerus 13:26, 25 September 2018 (EDT)

This field identifies what language the work is in, that is, it fills in the blank in the sentence "This work is in _____" The equivalent of "in French" is "in [a] Central American Indian language." --Vasha (cazadora de tildes) 13:45, 25 September 2018 (EDT)
I guess the difference between French and Bantu/Central American Indian/etc is that the former refers to "the French language" ("the one and only") while the latter refers to "a Bantu/Central American Indian/etc language" ("one of many".) Unfortunately, I can't think of a way to convey this difference without using an article or the plural form :(
It's even worse when dealing with creoles/pidgins. "A creole and pidgin, French-based" doesn't make sense. Perhaps "a French-based creole/pidgin"? Ahasuerus 14:45, 25 September 2018 (EDT)
Hmm, to me the fact that "language" is in lowercase sufficiently conveys that it is not the name of an actual language. But we need to hear from some people further outside the discussion on that. (as for creoles, it's "Creole OR pidgin, French-based") --Vasha (cazadora de tildes) 14:50, 25 September 2018 (EDT)
Well, that's what the ISO standard calls them: "Creoles and pidgins, French-based", "Creoles and pidgins, English-based", etc. "And" makes sense when describing a group of languages because the same code covers both creoles and pidgins. If we are to use the singular form ("creole", "pidgin"), we need to adjust the name. Ahasuerus 15:05, 25 September 2018 (EDT)

(unindent) After thinking some more about it, I agree that our best bet is to use the lower case form of the word "language" to indicate that it's "one of many". It's not perfect, but I agree that it's better than the plural form.

The first step will be to change "Mayan languages" to "Mayan language" in the software. If it doesn't cause any issues -- which it shouldn't, but you never know -- I will go ahead and add the languages discussed above. Ahasuerus 17:03, 28 September 2018 (EDT)

The change has been made. It's not retroactive due to the way I implemented language support back in 2010-2011 (a bad design choice which would be time-consuming to undo.) For this reason old submissions still show "Mayan languages" instead of "Mayan language" when you pull them up, but there are only 3 of them. Ahasuerus 17:29, 28 September 2018 (EDT)
Those three can be fixed by changing them to some other language and then back to Mayan. --Vasha (cazadora de tildes) 18:07, 28 September 2018 (EDT)
Oh no, the actual author records are OK, but the 3 submissions that set the language (like this one) still say "Mayan languages". It's not likely to be an issue since they were created and approved in 2017. Ahasuerus 18:14, 28 September 2018 (EDT)

Added languages - Part 1

The following languages have been added:

| Nilo-Saharan language            |
| Bambara                          |
| Bantu language                   |
| Niger-Kordofanian language       |
| Ewe                              |
| Igbo                             |
| Kamba                            |
| Kannada                          |
| Kikuyu/Gikuyu                    |
| Kurdish                          |
| Lingala                          |
| Creole or pidgin, French-based   |
| Central American Indian language |
| Nandi                            |
| Creole or pidgin, English-based  |
| Tigre                            |
| Tigrinya                         |
| Tsonga                           |
| Tswana                           |
| Zulu                             |

Ahasuerus 18:46, 29 September 2018 (ED

Great, thanks. --Vasha (cazadora de tildes) 15:29, 30 September 2018 (EDT)

Added Languages - Part 2

The following languages have been added:

  • Acoli
  • Fulah
  • Ganda
  • Kinyarwanda
  • Luo
  • Mandingo
  • Oriya
  • Pedi/Sepedi/Northern Sotho
  • South Ndebele
  • Southern Sotho
  • Standard Moroccan Tamazight
  • Wolof
  • North Ndebele

As I mentioned earlier, for now we use their ISO 639-2 names. AFAIK, this gives us what we need to enter the anthology which originally prompted this discussion. Ahasuerus 19:38, 1 October 2018 (EDT)

Right, they are all in there now. I just am going to keep arguing with you about the names. :-) --Vasha (cazadora de tildes) 19:42, 1 October 2018 (EDT)
It's a frustratingly complicated area for sure. I talked to a native speaker of Luganda/Ganda earlier today and it left me more confused than ever... Ahasuerus 20:52, 1 October 2018 (EDT)
Funny coincidence ... I just met a new neighbor today, and she's from Uganda. I asked her what her native language was, and she said "Luganda." Said she'd heard the name "Ganda" but it didn't seem right to her. --Vasha (cazadora de tildes) 19:04, 2 October 2018 (EDT)

New cleanup report - Magazine issues without fiction titles

A new cleanup report, "Magazines without Fiction Titles", has been deployed. It's similar to "Anthologies and Collections without Fiction Titles". The data will become available tomorrow morning. Ahasuerus 15:00, 2 October 2018 (EDT)

Will we be able to ignore? Because we have things like The New York Review of Science Fiction and Foundation that will pop up immediately - and these will never get resolved if we cannot ignore. And I would fight anyone that claims that these are out of scope :) Annie 15:12, 2 October 2018 (EDT)
Oh, sure. This report is basically a clone of "Anthologies and Collections without Fiction Titles", which supports the ability to ignore pubs. While I was testing it, I "ignored" a bunch of Locus issues and everything worked as expected. Ahasuerus 15:44, 2 October 2018 (EDT)
Oh yes, Locus as well. There will be a lot of ignores... Thanks for the confirmation! Annie 16:11, 2 October 2018 (EDT)
Any chance to "un-ignore" two records? this one and this one? If not, I will just keep them here as a record that they need content. Sorry - my finger was in the wrong line... Annie 14:56, 4 October 2018 (EDT)
Fixed.--Rkihara 12:15, 15 October 2018 (EDT)
Thanks a lot! Annie 12:38, 15 October 2018 (EDT)
I am afraid the ability to "unignore" records is currently unsupported. Since we have FR 768, "Add the ability to view 'ignored' records found by a cleanup report", I will go ahead and add the requested functionality to the FR. Ahasuerus 15:18, 4 October 2018 (EDT)
Suspected so but had to ask. Thanks! Will see if I can find the content for these two later. Annie 15:19, 4 October 2018 (EDT)

(unindent) Quick question - when something is solved, it looks like you need to wait for the nightly report for it to clear - see this one - Apex Magazine, March 2018 is now fixed but it is still in the list). Intentional? Annie 18:08, 4 October 2018 (EDT)

If I recall correctly, the cleanup report that I used as the template for these 2 reports had been coded that way for performance reasons. However, the new reports are unlikely to run into the same performance issue due to the way they are coded. Let me see what I can do... Ahasuerus 18:24, 4 October 2018 (EDT)
Done! Ahasuerus 19:47, 4 October 2018 (EDT)
Ah, that was quick! Thanks! Annie 11:37, 5 October 2018 (EDT)

NEED - to remove or not, that's the question...

Hello. I came across this title: NEEd. I read all (most) synopses and reviews (Amazon, Goodreads,,...) but couldn't find the slightest hint that this is spec-fic, except for the fact that Amazon catalogued it as such. Delete from the database? Flag as non-spec-fic with a note explaining? Other? Thanks! MagicUnk 15:51, 3 October 2018 (EDT)

From the descriptions, it sounds like it's somewhere between a thriller and near-future science fiction, the kind of grey-area that technothrillers inhabit, speaking about the impact of technology just one step away from what we know. If it's in a grey area and some people are categorizing it as speculative, I say keep it. --Vasha (cazadora de tildes) 16:17, 3 October 2018 (EDT)
It's grey all right :-) If no-one else chimes in, I'll follow your lead and keep it. Thanks! MagicUnk 18:05, 3 October 2018 (EDT)

Walker Books US (US) / Candlewick Press

Publisher Candlewick Press last year acquired US rights to the name "Walker" and now inaugurates its "Walker Books" US list. Today I updated a few records, mainly for publishers, but also one publication record P679266, which introduces the publisher name "Walker Books (US)".

1. I understand that any information added to the new publisher page will be deleted if its only publication record is revised to change the name. (Is it simply lost? That seems to me poor practice.)

2. Anyway, this is a good time to ask what should be the criteria for choosing one publisher name or another. Are we moving toward use of long spaced-slash(" / ") names whenever a hierarchical relationship is known? If so, which hierarchical relationships (stated "imprint", division, etc)? In this case:

  • Walker Books (US) --temporarily in the database after approval of my submission last hour
  • Walker Books U.S. (over a division of candlewick press) --homepage display; we don't use dots in this context, i understand
  • Walker Books US --Publishers Weekly in each its last two issues covers one publication evidently from the new list, and there designates the publisher "Walker Books Us"; Amazon reports "Walker Books US" for those two books
  • Walker Books / Candlewick Press --technically this one truly represents both imprint and division, i understand

One Amazon "Look inside" a Kindle edition (at Amazon US, the "other book", not in the database) shows 'title page'/screen with footer simply "Walker Books". Its copyright page/screen displays finally:

Walker Books
a division of
Candlewick Press
99 Dover Street
Somerville, Massachusetts 02144

"Look inside" the hardcover edition of "our book", for me now, does not show the title page, but a copyright page with the same display quoted above (at Amazon US, here now as the final screen).

One of those two "Looks inside" will be adequate for you when you read this, I hope, knowing that selection varies. --Pwendt|talk 19:22, 4 October 2018 (EDT)

Canonical name change: Julia K. Patt

Unless anyone objects, I am going to change Julia Patt's canonical name to Julia K. Patt (the way she has it on her website, for one thing). --Vasha (cazadora de tildes) 23:31, 4 October 2018 (EDT)

You may also want to look through some of the later ones that miss the K. - at least one actually has the K. on its site (this one while we do not). It may be a timing thing ( should be able to help) but just heads up. Annie 09:57, 5 October 2018 (EDT)
That one is correct because it is "Julia Patt" in the actual recording. --Vasha (cazadora de tildes) 12:28, 5 October 2018 (EDT)
Then a note is in order for the discrepancy between the web page and the recording - the same way we do that when a table of contents and a story title page differ. Annie 12:33, 5 October 2018 (EDT)

Canonical name changes: L. H. Moore, T. J. Berry, Laura Jamez

Three more changes needed: Lawana Holland-Moore to L. H. Moore; T. Jane Berry to T. J. Berry; L. E. Jamez to Laura Jamez --Vasha (cazadora de tildes) 14:16, 5 October 2018 (EDT)

Omnibuses without Contents Titles

The cleanup report Omnibuses without Contents Titles has been made available to non-moderators. Only moderators are able to "ignore" records. The change is effective immediately. Ahasuerus 15:16, 6 October 2018 (EDT)

"Pseudonym" vs. "alternative name"

The recent discussion of canonical names on the Rules and Standards page pointed out that the way we display what we call "pseudonyms" can be confusing. Here is what I wrote during the discussion:

  • At the moment William Fitzgerald Jenkins says "Pseudonym. See: Murray Leinster (or view all titles by this pseudonym)". Then, when you follow the link to the Murray Leinster page, you are told that "William Fitzgerald Jenkins" was his legal name, which is confusing. Similarly, Владимир Набоков tells you that it's a "pseudonym" even though it's merely the Russian form of Vladimir Nabokov's name.
  • ... the word "Pseudonym", which we use on Summary pages, could be replaced with something more generic -- like "Alternative name" -- which would help minimize confusion when our "pseudonym" is actually the person's legal name (see the Murray Leinster/Simon Hawke examples above.)

It seems like changing "Pseudonym" to "Alternative name" would be the low-hanging fruit in this case. If we decide to do that, we will presumably want to change "Pseudonym" to "Alternative name" in regular search, Advanced Author Search and on the "Make/Remove a Pseudonym" page. A few other places will need to be tweaked, but nothing significant. Of course, Help will need to be adjusted as well.

Does this make sense? Anything that I may be missing? Is there anything better than "Alternative name"? (We already say "Used As Alternate Name By" on Summary pages, so in a way it would be just streamlining the language.) Ahasuerus 17:59, 6 October 2018 (EDT)

Yep, that's good. Also covers the case where the "alternate name" is due to a misprint. --Vasha (cazadora de tildes) 18:13, 6 October 2018 (EDT)
If we used "Also published under:" (or "Also published as:"), it would (at least partially) address the transgender issue being discussed elsewhere. ···日本穣 · 投稿 · Talk to Nihonjoe 18:20, 8 October 2018 (EDT)

(unindent) The software has been changed to display "Alternate Name" instead of "Pseudonym". I believe all occurrences of the word "pseudonym" have been replaced except in mouse-over Help where it is used appropriately. If I missed anything, please let me know. Ahasuerus 15:24, 17 October 2018 (EDT)

Help has been updated. Ahasuerus 17:48, 17 October 2018 (EDT)
Help has been further cleaned up. While I was at it, I also deleted or rewrote many obsolete and/or ambiguous paragraphs which were created in the early days of ISFDB 2.0 when the software was very different. Some "How To" pages will also need to be updated. Ahasuerus 15:34, 19 October 2018 (EDT)

Web API enhancements

The part of the Web API responsible for retrieving publication data in response to third party queries has been enhanced. It now correctly returns all publications whose ISBN matches the queried ISBNs regardless of how many variations of that ISBN (ISBN-10 vs. ISBN-13) we have on file. In addition, non-standard dates (0000-00-00, 8888-00-00 and 9999-00-00) are now returned in the format that we use on bibliographic pages.

This is step one in a series of Web API enhancements requested by Fixer in order to facilitate building submissions for ISBN-less pubs. Due to the recent increase in the number of ISBN-less pubs, the fact that Fixer can only create submissions for ISBN-enabled pubs has become a problem and I am working on addressing it. Ahasuerus 14:13, 8 October 2018 (EDT)

Third parties can now use External IDs (ASINs, LCCNs, OCLC numbers, etc) to query the ISFDB Web API. The documentation page has been updated. Ahasuerus 17:32, 8 October 2018 (EDT)
Thanks for updating the APIs! Annie 17:38, 8 October 2018 (EDT)
Sure thing! Fixer says that he will give me a biscuit and even take me for an extra long walk tonight. Ahasuerus 17:56, 8 October 2018 (EDT)

(unindent) Fixer has been upgraded to leverage the new API and to submit ISBN-less publications. At the moment it's not as robust as the rest of Fixer's logic, e.g. it doesn't support internal prioritization, but it lets us handle ASIN-only ebooks in a semi-automated fashion. I plan to use J-Novel Club, which didn't use ISBNs in 2016 and early 2017, as a guinea pig. Ahasuerus 14:39, 15 October 2018 (EDT)

Development server -- technical difficulties

The development server is experiencing technical difficulties at the moment. If I disappear for a couple of days, I am probably deep inside its guts trying to resurrect the beast. Ahasuerus 13:09, 16 October 2018 (EDT)

Watch for facehuggers. The cthulhu are your friends. --Marc Kupper 18:17, 16 October 2018 (EDT)
Thanks for the tips! The development server is now fully operational. Fixer says "Not that I absolutely need independently-turreted 200cm Hellbores on this backward planet, but it's the thought that counts." Ahasuerus 17:12, 17 October 2018 (EDT)


Can we add Montenegrin (cnr in iso639-2)? Ognjen Spahić does not write in Serbian and the translation is clearly marked as translation from Montenegrin (for example in the award announcement). Considering that iso639-2 recognizes it as a separate language, I would rather not have it lumped with Serbian here... Annie 20:04, 17 October 2018 (EDT)

Done! ISO 639-2-recognized languages are child's play compared to the rest of them :) Ahasuerus 22:20, 17 October 2018 (EDT)
Thanks. I remembered that you mentioned that so did my homework and pulled the code while I was at it. :) Annie 22:35, 17 October 2018 (EDT)

Dangling Propositions

DANGLING PROPOSITIONS: "The Superstoic" "Instrument" "Not to Behold", by Billy Sledge, is available as both an ebook and a paperback on Amazon Books. —The preceding unsigned comment was added by Bsledge (talkcontribs) .

Added -- thanks! Ahasuerus 14:16, 20 October 2018 (EDT)

"Juvenile" chapbooks—search advice?

I have been marking the CHAPBOOK record juvenile if the contained story is juvenile, but it just occurred to me that that doesn't entirely make sense; a CHAPBOOK has no text and can't really be juvenile or not. --Vasha (cazadora de tildes) 17:04, 20 October 2018 (EDT)

Well, COLLECTIONs can be "juvenile" and you can think of CHAPBOOKs as single-story COLLECTIONs. Ahasuerus 18:04, 20 October 2018 (EDT)

Be that as it may, what I really want is an easy way to find chapbooks with juvenile stories in them, whether they're marked or not. Can anyone think of a way to search for them? --Vasha (cazadora de tildes) 17:04, 20 October 2018 (EDT)

It can be done with a custom database search run against a recent backup, but I can't think of a single Advanced Search query that would do it. Depending on the ultimate goal, it may be doable via a new cleanup report. Ahasuerus 18:04, 20 October 2018 (EDT)
Reasons for doing this ... I have been trying to check newly-entered 2018 short fiction to make sure it has length specified if possible and make sure it is really first published in 2018. To make the task a little more manageable, I decided to ignore juvenile fiction. So, ideally I look at non-juvenile anths, colls, and magazines, see if they need more data or contents added, and then mop up remaining short fiction by looking at non-juvenile chapbooks. It would speed things up if I could eliminate the juvenile ones in one step.
If marking chapbooks juvenile is legit, then they should all be marked. Reason enough for a cleanup report. --Vasha (cazadora de tildes) 18:34, 20 October 2018 (EDT)
Sounds good. FR 1206 has been created. Ahasuerus 12:46, 21 October 2018 (EDT)
There are probably a few juvenile chapbooks with non-juvenile Shortfiction too; I know I found one once. Maybe you could generalize the report to mismatches of either type. --Vasha (cazadora de tildes) 14:24, 21 October 2018 (EDT)
I guess it raises a larger question: do we want all four title flags -- juvenile, non-genre, novelization, and graphic -- to match for CHAPBOOK/SHORTFICTION pairs? Ahasuerus 15:12, 21 October 2018 (EDT)
Good question, I don't know. In the case of "juvenile," the match is not obligatory because there could be good reasons for the chapbook to be juvenile and the story not; this juvenile edition of a Kafka story for example. The others ... I can't think of a reason why they might mismatch. --Vasha (cazadora de tildes) 15:58, 21 October 2018 (EDT)
Hm... It looks like this chapbook reprinted the original (well, translated) text of the Kafka story without making any changes, but the presentation made it look like a juvenile, right?
It raises an interesting question. Many classic works which were originally written with adult audiences in mind have had juvenile-friendly editions: Robinson Crusoe, Gulliver's Travels, etc. Similarly, the Harry Potter books have been published with different covers, some aimed at adults and some at kids. Sometimes Harry Potter publishers even state that it's an "adult edition" vs. a "juvenile edition."
For novels, we can't capture this information except in Notes because the juvenile flag exists at the title level. For chapbooks, we have the ability to capture it, but I am not sure it's ideal. What happens if a publisher prints two versions of a chapbook, one for adults and one for kids? Should we have two separate CHAPBOOK titles for the book? Ahasuerus 10:53, 22 October 2018 (EDT)
It is a bit of a mess. The theory that a chapbook is just a neutral container for for a story breaks down a bit because of all the other things besides the story it can contain: essays, illustrations, etc. Another time when this theory got challenged was when I entered a review of a heavily-illustrated chapbook that talked as much about the illustrations as about the story (the story had been published before but the illustrations were new)—it is standard to link the review to the SHORTFICTION record in reviews of chapbooks, so I did that and made a note that it was a review of the illustrated chapbook edition. That case challenges the logic of linking to the SHORTFICTION rather than the title which contains both the story and the illustrations. So maybe we should be paying more attention to chapbooks as something in their own right, with their own properties: the sum total of all their contents, and the editorial presentation of the chapbook, give it the properties. Come to think of it, I could imagine an illustrated chapbook being a "graphic" work even if it contains the word-for-word text of a story. --Vasha (cazadora de tildes) 23:10, 22 October 2018 (EDT)

(unindent) Backtracking here: we don't need to decide all the theoretical issues right now, if you could just implement the cleanup report in the simple form you first proposed so that I could get on with what I'd be using it for! --Vasha (cazadora de tildes) 23:10, 22 October 2018 (EDT)

Sounds good, I'll see what I can do tomorrow. There are only 272 ISBNs left in Fixer's internal queues for this monthly cycle, so at the moment I am actually ahead of schedule for a change. Ahasuerus 22:32, 24 October 2018 (EDT)
A new cleanup report to find CHAPBBOOK/SHORTFICTION juvenile flag mismatches has been coded and deployed. The data will become available tomorrow morning. Ahasuerus 16:47, 25 October 2018 (EDT)
Thanks a lot! --Vasha (cazadora de tildes) 17:00, 25 October 2018 (EDT)

Multiple series - a stopgap measure?

While allowing a title (or a publication?) to be in multiple series is still on the drawing board, could we consider a stop-gap measure of creating a template (or two) that would at least allow us to a) document how desirable the feature is and b) keep us from losing track of which entries would need to be updated once the feature was allowed and c) possibly allow for more thorough searches? ../Doug H 16:00, 21 October 2018 (EDT)

P.S. Earlier discussions found no reason to have multiple/nested publication series. Jules Verne's Voyages Extraordinaire was essentially a publication series, but the books were also part of either Collection Hetzel, Collection Hachette or Magasin d'Education et de Recreation. ../Doug H 16:00, 21 October 2018 (EDT)

I have seen quite a few cases of books in multiple publication series. All the examples I can think of right now are Spanish-language publications. --Vasha (cazadora de tildes) 17:10, 21 October 2018 (EDT)
I have seen a few English-language pubs that belonged to 2 separate publication series.
Actually, allowing multiple publication series per publication record wouldn't be too hard to do because publication series cannot be nested. Ahasuerus 20:04, 21 October 2018 (EDT)
Example of nested publication series, from LTF: Criptonomicón I. El código Enigma as "Byblos 1362" and "Byblos Neal Stephenson 1." --Vasha (cazadora de tildes) 21:12, 21 October 2018 (EDT)
I suppose various "Masterworks" pub series could also be usefully organized hierarchically. Ahasuerus 09:50, 22 October 2018 (EDT)
Title series present a more difficult challenge. If a title belongs to two separate sub-series within the same parent series, as was the case with R. A. Salvatore's Servant of the Shard, the display logic can get hairy. Probably still doable, though. Ahasuerus 20:04, 21 October 2018 (EDT)
See also the UniCorp series and its sub-series Trilogía de Benigno Manso. The authors assign those three novels as both 1, 2 and 3 of the Trilogía, and numbers 18, 21, and 26 of the UniCorp series.
The title series issue could be handled by displaying the title twice, if this isn't completely undesirable—probably that's the crux of the matter. The UniCorp example could look like this:
3 Sombras de honor (2008)
18 (Also Trilogía de Benigno Manso 1) La embajada (2000)
39 La cosecha del centauro (2009)
Trilogía de Benigno Manso
1 (Also UniCorp 18) La embajada (2000)
What do you think? --Vasha (cazadora de tildes) 21:12, 21 October 2018 (EDT)
Do not add more stuff between the title and the number - it is already hard to read with some long titles and adding more stuff won't make it easier to read or to copy off the page when you want to. I am all for having it at the end of the line - just after the year and the "only by" when these a presented but not that early on the line. Annie 23:21, 21 October 2018 (EDT)
Keep in mind that a true "multi-field" can have any number of values. For example, What Lay Beyond, book 7 in our "Star Trek: Gateways" crossover series, is also a part of the following timelines/series:
  • Star Trek TOS
  • Star Trek Challenger
  • Star Trek TNG
  • Star Trek DS9
  • Star Trek Voyager
  • Star Trek New Frontier
That's what makes the issue so thorny. Ahasuerus 09:58, 22 October 2018 (EDT)
Yeah, there is that one. There are a few like that in the Trek cannon, not just the Gateways. And then there are a few fantasy series that have subseries inside of the series and all kind of other... fun. Annie 17:33, 22 October 2018 (EDT)
Another display idea (just a thought--I think this looks OK, even for the really long one) I put the "also part of" in bold-itals to distinguish it from the Translations and Variants that are also in the same place under the title. I think if there were both translations and multiple series then the series notation would go under the translation notation. --Vasha (cazadora de tildes) 19:39, 27 October 2018 (EDT)
12 La voz del héroe (1997) [SF] by Eduardo Gallego and Guillem Sánchez
13 Nàufrags en la nit (1998) [SF] by Eduardo Gallego and Guillem Sánchez also appeared as:
Translation: Un cruce en la noche [Spanish] (2004)
14 Dime con quién andas ... (1996) [SF] by Guillem Sánchez and Eduardo Gallego
17 Después del Desastre (2002) [SF] by Eduardo Gallego and Guillem Sánchez
18 La embajada (2000) by Eduardo Gallego and Guillem Sánchez
Also part of: Trilogía de Benigno Manso (1)
19 La llanura (1998) [SF] by Eduardo Gallego and Guillem Sánchez
20 Fortaleza de invicta castidad (2001) [SF] by Eduardo Gallego and Guillem Sánchez
21 Asedro (2001) by Eduardo Gallego and Guillem Sánchez
Also part of: Trilogía de Benigno Manso (2)
22 Inmigrantes (1996) [SF] by Eduardo Gallego and Guillem Sánchez

Star Trek Gateways
7 What Lay Beyond (2001) [A] by Keith R. A. DeCandido and Susan Wright and Diane Carey and Robert Greenberger and Peter David and Christie Golden
Also part of: Star Trek TOS, Star Trek Challenger, Star Trek TNG, Star Trek DS9, Star Trek Voyager, Star Trek New Frontier

(unindent) I didn't really want to re-hash the reasons for and against implementing multiple series or the possible implementations. I was hoping a Template (or one each for title and publisher series) would be simple to implement, provide consistency of entry and display, track prospective entries and identify possible issues for such a discussion. ../Doug H 09:02, 22 October 2018 (EDT)

A template or two would be easy to add. Would something like "MultipleSeries" and "MutliplePubSeries" be sufficient? Ahasuerus 09:47, 22 October 2018 (EDT)
Would "AdditionalTitleSeries" and "AdditionalPubSeries" be clearer? ../Doug H 09:57, 22 October 2018 (EDT)
Sure, we can do that. Ahasuerus 11:11, 22 October 2018 (EDT)
Do templates support abbreviations? ../Doug H 09:57, 22 October 2018 (EDT)
Template names can't be abbreviated at this time. We could create two differently named templates with the same functionality, but I am concerned that it may confuse less experienced editors. Ahasuerus 11:11, 22 October 2018 (EDT)
I'd go for clarity over brevity. One long name each, with Additional making it clearer it is to support series other than the one already specified by the Series attribute.
I've gotten used to Tr for translate, any chance of ATS/APS? ../Doug H 09:57, 22 October 2018 (EDT)
We have full control over template names, so we can do whatever we want. A lot of our template names are abbreviations, although most of them are names of established third party sites like OCLC and BnF. Ahasuerus 11:11, 22 October 2018 (EDT)
Presumably parameters would be series name and optional sequence. ../Doug H 09:57, 22 October 2018 (EDT)
I am afraid that, unlike the Wiki software, the ISFDB software supports only one parameter per template at this time. Given this limitation, it would have to be the "other" series name; series numbers would be unsupported. Unfortunately, series names are less stable than record numbers. Also, it would only work for titles which belong to 2 series. Ahasuerus 11:11, 22 October 2018 (EDT)
This is just documentation, names are good enough. As long as the text wrapper for the templates allow one to include the sequence if needed it will work. Based on the ISBN template for additional ISBNs (no longer necessary I presume), my suggestion is to display the words "Additional title|publication series" followed by a space and the specified parameter. Although to follow through on the idea, the names should be shortened to TitleSeries and PubSeries. ../Doug H 11:40, 22 October 2018 (EDT)
So the end result for R. A. Salvatore's Servant of the Shard would be "Additional title series Forgotten Realms: The Sellswords, volume 1", right? Would "Also in title series Forgotten Realms: The Sellswords, volume 1" be clearer? Ahasuerus 12:50, 22 October 2018 (EDT)
"{{TitleSeries | Forgotten Realms: The Sellswords}}, volume 1" would be my preference to generate your text. ../Doug H 14:41, 22 October 2018 (EDT)
If I understand everything correctly, then the current version of the proposal is to create two linking templates, {{TitleSeries}} and {{PubSeries}}. Each one would take one parameter. When displayed, the proposed templates would expand to "Also in title series NNN" and "Also in publication series NNN". NNN would be replaced with a regular Search link to the title/publication series with the parameter value used as the search value. It would be similar to the way "Husband of {{A|Tabitha King}}." is replaced with
Husband of <a href="">Tabitha King</a>
on Stephen King's Summary page. Is that about right? Ahasuerus 16:13, 22 October 2018 (EDT)
I hadn't been thinking it was a linking template. If you do that, then I'd drop the extra text of "Also in" and consider dropping the "title series" and "publication series" to make it behave exactly the same way as the {{A|}} and let people string together sentences the way they want. ../Doug H 17:28, 22 October 2018 (EDT)
Sure, we can do that. Ahasuerus 11:36, 23 October 2018 (EDT)
P.S. If we do, perhaps we should call the new templates something like {{S}} and {{PubS}} to be consistent. Ahasuerus 11:55, 23 October 2018 (EDT)
While I am all for uniformity, I would make the case that we should have separate templates than standard S and PubS ones if we plan to change the UI at some point to get them shown differently. I can see myself using S or PubS in all kinds of notes to reference a series/pub series and not just for indicating inclusion. We can just do that of course but then we are facing yet another long cleanup in splitting the "this is also part of a series" from "and we just references a series"... On a very separate note, if we add them, they also need to be added to the report that checks for invalid ISFDB references :) Annie 12:55, 23 October 2018 (EDT)
Fair enough. In that case, perhaps we should create two sets of templates:
  • "S" and "PubS" for arbitrary references to series/pub series
  • "MultiS" and "MultiPubS" for multi-series titles and pubs
Ahasuerus 15:33, 23 October 2018 (EDT)
Yep - sounds good to me. Annie 15:58, 23 October 2018 (EDT)
If the series doesn't exist, what happens? ../Doug H 17:28, 22 October 2018 (EDT)
You'll get a blank page which will say A search for 'test series' found 0 matches. Ahasuerus 11:36, 23 October 2018 (EDT)
I like the look of using a bullet to denote the sequence (i.e. • 1) the way it shows up on the title reference on the publication. Is there a template for bullet? ../Doug H 14:41, 22 October 2018 (EDT)
Not at this time, but we could easily create one if desired. Ahasuerus 16:13, 22 October 2018 (EDT)
Anyone who can learn the name of the bullet template can learn to type "&bull;".--Vasha (cazadora de tildes) 13:11, 23 October 2018 (EDT)
I guess you could cut/paste the character. Anyway keeping just the series name in the template should simplify organizing a conversion if we ever get around to it. I figured the "Also in" text didn't help with readability. ../Doug H 14:41, 22 October 2018 (EDT)
My concern with "Additional title|publication series" was that if a "naive" user were to come across that wording in a Note field, it might not be immediately clear what it was in reference to. Hopefully other editors will chime in re: readability. Ahasuerus 16:13, 22 October 2018 (EDT)
How about "Title also belongs to "name" series" or "This title is also "Test #1"" where the template parameter will need to be the complete string we want to show. Or maybe string 2 templates next to each other ({{AddSeries|Test}}{{number|1}} will become "This title is also in Series Test (as number 1)". If you miss the second template, it does not have the element in the brackets)? Same for pub series. Annie 17:33, 22 October 2018 (EDT)
Also, how would you leverage these templates to handle What Lay Beyond which I mentioned earlier? Use the "Additional title series" template 6 times, once per additional series? Ahasuerus 12:50, 22 October 2018 (EDT)
Most cases have only one additional. For such rare occurrences, repeating the template seems reasonable, especially since it would help with searches. ../Doug H 14:41, 22 October 2018 (EDT)
Not different from multiple templated OCLCs for example - repeat the template as many times as you need to. Annie 17:33, 22 October 2018 (EDT)
Makes sense. Ahasuerus 15:33, 23 October 2018 (EDT)

Finalizing the wording of MultiS and MultiPubS

Now that "S" and"PubS" have been added, we need to finalize the wording of "MultiS" and "MultiPubS". Based on the discussion above, we have the following scenarios:

Publication series:

  • Also part of Ace Double
  • Also volume D-343 in Ace Double

Regular/title series:

  • Also part of Trilogía de Benigno Manso
  • Also volume 1 in Trilogía de Benigno Manso

What should "MultiS" and "MultiPubS" expand to in order to accommodate these scenarios? Ahasuerus 18:29, 26 October 2018 (EDT)

With a bit of rewriting (and a third template ("Vol" for example) - because we cannot pass 2 parameters, right?):
  • {{MultiPubS|Ace Double}}: Also part of Ace Double
  • {{MultiPubS|Ace Double}} {{Vol|1}}: Also part of Ace Double(as volume 1)
Any chance we can make them work both with names and with IDs? I doubt it but have to askAnnie 21:59, 26 October 2018 (EDT)
Not at this time, I am afraid. Ahasuerus 22:07, 26 October 2018 (EDT)

Links from Facebook

If someone posts a link to one of our listings on ISFDB, Facebook now appends a really long Facebook Click ID to the URL (example). Can we update the database to strip the "&fbclid=" and the ID from the URL when it comes here so the links will work? ···日本穣 · 投稿 · Talk to Nihonjoe 16:24, 24 October 2018 (EDT)

It looks like they started doing it earlier this month. I've created FR 1207 to ignore the Facebook parameter - thanks! Ahasuerus 16:58, 24 October 2018 (EDT)
Awesome, thanks! ···日本穣 · 投稿 · Talk to Nihonjoe 17:19, 24 October 2018 (EDT)
After experimenting with this issue, I realized that this is a fairly big can of worms. As Wikipedia explains, most URL queries look like . Facebook assumes that all Web sites use this format and appends another parameter, "fbclid", to each external URL. They figure that another parameter shouldn't prevent third party Web sites from parsing the rest of them correctly.
However, that's not how most of our Web pages (searches are an exception) work. Our URLs look like , and so on. Note that there is no equal sign in these URLs. If we need to pass an additional parameter, we use the "+" sign, e.g. .
What this means is that our URLs are incompatible with what the Facebook software expects. It may be possible to beef up our parsing algorithms to extract IDs from the hybrid URLs that Facebook uses, but it's a pretty big deal. For starters, every ISFDB page does its own parameter parsing, so we would first need to centralize the parameter parsing process, which would literally affect every Web page that we have.
Hopefully Facebook will realize that not every Web site uses the URL format that they expect and stop appending "fbclid" to incompatible URLs. Ahasuerus 21:33, 26 October 2018 (EDT)

Note Search

A new section, "Note Search", has been added to the Advanced Search page. The functionality is relatively basic compared to the main Advanced Search sections and should be self-explanatory. All record types -- authors, awards, publishers, series, etc -- are searched, so it usually takes a few seconds to compile the results. Please note that the search logic also scans the Synopsis data. Ahasuerus 19:52, 24 October 2018 (EDT)

Yey! Thanks for building this! Annie 19:57, 24 October 2018 (EDT)
Awesome! Will it be added to the main search box? ···日本穣 · 投稿 · Talk to Nihonjoe 20:44, 24 October 2018 (EDT)
I don't think it's something that we have discussed before. If there is demand, I can certainly add "Notes" to the regular search box. Like other regular search options, it would assume the "contains" (as opposed to "starts with" etc) parameter. Ahasuerus 21:11, 24 October 2018 (EDT)
How hard is that query on the DB? Everything else looks at a single short-ish field; that one can get a bit gnarly (if you look for "a" for example). Annie 21:13, 24 October 2018 (EDT)
It's rather intensive since each search has to parse up to 90 MB of data. The "regular" search logic doesn't support single character searches for most search types, so at least "a" shoudn't be an issue if we were to add "Note" to the drop-down list. Still, it can take over 5 seconds to complete a Note search, so it's pretty impactful. Ahasuerus 22:29, 24 October 2018 (EDT)
I know that I keep hitting "search" with a wrong category often - while you need to go into the Advanced Search as it is now. And "an" is bad enough anyway. Or "th" :) If everyone wants it, please, do not mind me but I would rather not see it on the outside list... Annie 22:33, 24 October 2018 (EDT)

While we're on the subject of searching—why is it not possible to use the OR operator when searching tags? (I may not understand the answer, but ...) It would be handy to be able to search for "science fiction OR sf," for example. --Vasha (cazadora de tildes) 22:09, 24 October 2018 (EDT)

Actually, it's the other way around: OR is supported but AND is not. A search on vampire OR vampires succeeds while a search on vampires or werewolf fails.
The reasons are highly technical in nature. There are other Advanced Search quirks which I'd like to address, e.g. Bug 690 ("Advanced Searches on 'not exactly' and 'does not contain' can fail") and Bug 571 ("Advanced Search on Web Pages fails for OR searches"), but it would require a fair amount of tinkering. Ahasuerus 22:21, 24 October 2018 (EDT)
Hi Ahasuerus. I was checking both bugs you mention above. What I was wondering, aren't these easily solved by using (left or right) outer join on the involved table fields in your query? And if there're limitations in the querying language you use, the same effect can be achieved with a union. Or am I missing something here? MagicUnk 02:37, 26 October 2018 (EDT)
Yes, outer joins are the way to go and yes, they are supported by the version of MySQL that we are currently using. However -- there is always "however", isn't there? -- our Advanced Search logic is a fairly big can of worms which has evolved over the years. It's vastly better than it was 5-10 years ago, but it's still suboptimal. For starters, it tries to accommodate arbitrary combinations of ANDs/ORs, but doesn't do a good job of it.
The first step will be to eliminate the AND/OR mess. The second step will be to rewrite Advanced Search to address FR 1142 and FR 1143. Once that is done, we will be able to go back and address the outer join issues. No rest for the wicked! :-) Ahasuerus 13:14, 26 October 2018 (EDT)

(unindent) The Note Search has been further enhanced. Authors are now displayed alphabetically based on the directory entry/family name. Notes which leverage the "BREAK" template are now fully displayed. Ahasuerus 13:56, 26 October 2018 (EDT)

A quick question: " Note Search is currently limited to the first 1000 author matches plus up to 1000 other matches. ". Why the authors are singled out here? It may be just my usage pattern but I rarely look for author notes (as opposed to links - there I am more likely to look for authors indeed) so it would be more logical to have either publications or titles being singled out on their own outside of the 1000. Are the notes for authors handled differently in the DB? Annie 14:23, 26 October 2018 (EDT)
That's right, Author Notes, which were added in 2017, are handled differently by the database/software. All other types of notes are stored in one big table, which is ... suboptimally organized. It's one of the few remaining legacies of the "ISFDB 1.0" software which we used in 1995-2005. I plan to rewrite it one of these days. Hopefully sooner rather than later. Ahasuerus 15:38, 26 October 2018 (EDT)
That explains it. Well, I guess I will need to get the numbers under 1000 to see all of the non-publication references :) Thanks! Annie 15:57, 26 October 2018 (EDT)

Reorganizing data-entry fields: how difficult?

While entering new pubs I notice I need to scroll up and down a lot, and do not really have a good overview of what data I've already entered. Looking at the fields and the average length of the data it holds, I was wondering if it's possible/easy to do to rearrange some of the now vertically-arranged fields to horizontal. I don't know if this has been discussed before but it would save space to have, for example, the Juvenile, Novelization, Non-Genre, Graphic Format checkboxes on one line. Likewise, it could save space to have ISBN & Catalog ID fields, and Pub Series & Pub # similarly arranged horizontally. Thoughts? MagicUnk 13:02, 25 October 2018 (EDT)

Just a comment: some people work on small screens often... I often do quick edits from my phone for example and the screen on my home chromebook may not be as small but it still is much smaller that you would think (and fitting all 4 field names and checkbox for example won't work there). And Publication Series can be a long string - making it shorter so we can fit a number next to it does not make sense. If we go for a reordering, can we please make it optional? :) Annie 13:15, 25 October 2018 (EDT)
Moving fields around is easy, we'll just need to make sure that we do it consistently across all data entry forms. I was thinking about putting the four title check-boxes on the same line myself the other day.
Re: Annie's point about small screens, I can see how it would make putting the Series and Pub. Series fields on the same line problematic. Ahasuerus 13:18, 25 October 2018 (EDT)
It is not just small screens I think. I know that we had at least a few editors working under magnification - which will also make the screen unwieldy when it gets too wide. Although the more I think about the 4 checkbox, the more I start agreeing that they take too much space now :) Annie 13:31, 25 October 2018 (EDT)
Just for clarity's sake, the examples I gave above are just that, examples. I did not mean to rearrange in such a way that they would extend beyond the length of the already existing input fields (which are at least 80 chars wide if I counted correctly). Rearranging can be done in such a way that small screens do not suffer. As an example, if you count the characters of the longest label+checkbox, the length is only 19 chars [Graphic˽Format:˽?˽□ (where ˽ denotes space)]. 4 fields x 19 chars = 76 chars max - would fit nicely below the 'Content' bar with space to spare if you consider the 28 positions for the label (which I didn't count).
As for the pub series name & number example: Ahasuerus, can you to a group by max(lenght(string)), count query so we have an idea about the max length of a pub series name? Can't imagine it extend (much) beyond 40 or so chars... Cheers! MagicUnk 18:36, 25 October 2018 (EDT)
Behold -- our longest publication series name, Illustrierte Weltall-Bibliothek - Fesselnde Erzählungen, Abenteuer u. Forschungsreisen aus allen Gebieten des Weltalls! :-) Ahasuerus 20:38, 25 October 2018 (EDT)
Arghlp! So, I guess best not to touch the series fields then. But what about other real-estate-saving shuffling around of fields (like the checkboxes)? Still a good idea? MagicUnk 02:01, 26 October 2018 (EDT)
The three editors who have commented so far all seem to agree that putting the title flags/checkboxes on the same line is a good ideas, so I have created FR 1208 for this enhancement.
Come to think of it, it may also help in other ways. There have been times when I accidentally checked the wrong box. Hopefully displaying them horizontally will make misclicks less likely. Ahasuerus 12:54, 26 October 2018 (EDT)
Another thing that might reduce errors is to make sure the boxes are in the same order everywhere they appear (they currently are not). --Vasha (cazadora de tildes) 14:40, 26 October 2018 (EDT)
Oops, I had no idea! Thanks for pointing it out. Bug 712 has been created. Ahasuerus 15:17, 26 October 2018 (EDT)
Fixed. Ahasuerus 22:18, 26 October 2018 (EDT)
ISBN and Catalog ID on one line is not a bad idea either. --Vasha (cazadora de tildes) 14:31, 26 October 2018 (EDT)
True, but we plan to allow multiple ISBNs per publication -- Real Soon Now (tm) -- at which point things will change. Ahasuerus 15:17, 26 October 2018 (EDT)

Web Page Search

As per FR 1141, "Web Page Search" has been added to the Advanced Search page. The functionality is similar to the previously added Note Search functionality except the search logic checks third party Web site URLs across all record types. For example, here is what you will get if you search for "user". Ahasuerus 23:09, 25 October 2018 (EDT)

Now that's scary - you managed to get it done while I was planning to ask you to do a search at all web pages fields pointing to (we had some of .the txt links in the notes (which had been dead for awhile) - I moved those to the new .htm format last night but was not sure what we have in weblinks...). Thanks! Annie 23:31, 25 October 2018 (EDT)
You are welcome! This functionality was originally requested at the same time that the Note search functionality was requested. In addition, the search logic is similar, so once the Note Search module was completed, it was relatively easy to create the Web Page Search module.
In the meantime I have deployed another patch to clean up the way the data is displayed. The most obvious changes are:
  • Third party URLs are now hyperlinked
  • Author names are now alphabetized based on each author's directory entry/family name
Ahasuerus 12:43, 26 October 2018 (EDT)

2 new linking templates: PubS and S

Two new linking templates have been created for publication series and regular series: {{PubS|[pub. series name]}} and {{S|[series name]}}. Help:Using_Templates_and_HTML_in_Note_Fields#Linking_Templates has been updated. Ahasuerus 18:17, 26 October 2018 (EDT)

Very Far Away from Anywhere Else

Usula K. Le Guin's Very Far Away from Anywhere Else is marked "juvenile" and I think it doesn't fit that—the main characters are 17 years old, audience not much younger. The standard codes we follow as a guideline for age ranges (I'm blanking on the name of it) has "juvenile" being up to age 15 or so. Any objection to my removing the juvenile flag? --Vasha (cazadora de tildes) 03:07, 27 October 2018 (EDT)

Sounds like a good plan. Ahasuerus 10:08, 27 October 2018 (EDT)
Not sure if that's rhe right thing to do. Our juvenile flag covers both juvenile and young adult. It is impossible to clearly define, but young adult is targeted to ages 16 to 21 (roughly). So, if that's the target audience, it should remain tagged as juvenile. MagicUnk 03:50, 28 October 2018 (EDT)
Agreed. Template:TitleFields:Juvenile specifically says "targeted at the juvenile or Young Adult market". Maybe we should rename the field (though there is not an easy name that encompasses all that I can think of) or just delete it... -- JLaTondre (talk) 09:27, 28 October 2018 (EDT)
For some reason I thought that the last round of the relevant Rules and Standards discussion didn't explicitly include YA fiction, but I see that I was misremembering. Sorry about that!
That said, I think our current usage may be different. Let me run a few queries to see how many titles with YA/teen tags also have the "juvenile" flag set. If the percentage is as low as I suspect it is, I will post on the R&S page. Ahasuerus 11:16, 28 October 2018 (EDT)
Here are the results. Definitions:
  • A "YA tag" is a tag that starts with "teen " or contains "young adult"/"young-adult"
  • A "juvenile tag" is a tag that starts with "child "/"children" or contains "juvenile"
Note that some titles are on the border between "juvenile" and "YA", so they have both "juvenile" and "YA" tags. With that in mind:
  • Total titles with "YA" tags: 12,047
  • Total titles with "YA" tags and no "juvenile tags": 11,030
  • Titles with YA tags which also have the "Juvenile" flag set: 3,731
  • Titles with YA tags and no juvenile tags which also have the "Juvenile" flag set: 2,732
This means that of the 11,030 "pure" YA titles only 2,732 -- or 24.77% -- have the "Juvenile" flag set. I think this is enough to start a Rules and Standards discussion, so I will re-post the investigation results there. Ahasuerus 12:12, 28 October 2018 (EDT)

Wool-gathering (transferred)

I am transferring here the exchange I've just had with Ahasuerus. Any other commentaries / suggestions / horror screams from the community ?

As I am ploughing (U.S. : plowing) through all sorts of pub series at the moment, a few ideas crossed my mind, which, no doubt, other editors have had before. There is nothing urgent about all this — more wool-gathering than anything else — but if anything can come out of it, all the better.

Crossover series

Would there be a way to make a title (typically, e.g. Frankenstein Meets Dracula) belong to distinct series ? There are more and more stories of this type, mixing up characters from different horizons. Linguist 12:30, 26 October 2018 (EDT).

There is a Feature Request (FR 406) to "Allow multi-series titles" and a related ongoing discussion of overlapping and hierarchical publication series here. Since crossover series are becoming more common, we may want to make this FR a higher priority. It's not that hard to do from a purely technical perspective, but first we need to decide how the software should behave in unusual cases, e.g. what we should do with a title that belongs to 7 series -- see the discussion linked above. Ahasuerus 18:52, 26 October 2018 (EDT)
As Ahasuerus points out, there is already a discussion on this further up the page. It would be better to keep the discussion consolidated there. -- JLaTondre (talk) 09:28, 27 October 2018 (EDT)

Art title series

Could the series concept be applied to art titles ? I tried it once, and the result was that the concerned titles appeared grouped together, but without a common title name. This would mainly concern covers with an identical art element, as part of a book series (as in this one for instance). Linguist 12:30, 26 October 2018 (EDT).

Checking the software, I see that the following title types let you enter series information, but are not organized as series on Summary pages: COVERART, INTERIORART, REVIEW, INTERVIEW. I can't think of a good reason to prevent editors from organizing these types of titles as proper series, so I would support changing the software behavior. Would you like to post a proposal on the Community Portal? Ahasuerus 19:02, 26 October 2018 (EDT)
FR 1213 has been created. Ahasuerus 12:48, 3 November 2018 (EDT)

Viewing title series covers

Would there be a way to view all the cover illustrations of an existing series ? Linguist 12:30, 26 October 2018 (EDT).

At this time you can view all cover images for a publication series -- e.g. Nouveaux Millénaires -- but not for a regular/title series. Since cover images are associated with publication (as opposed to title) records, it didn't seem desirable. However, it wouldn't be that hard to do from the technical perspective and I can certainly implement the functionality if there is support on the Community Portal. Ahasuerus 19:07, 26 October 2018 (EDT)
FR 1214 has been created. Ahasuerus 12:52, 3 November 2018 (EDT)

Viewing an artist's illustrations

Would there be a way to view all the cover illustrations by the same artist ? That would be a great help in finding variants. TIA, Linguist 12:30, 26 October 2018 (EDT).

It's certainly doable. The only concern that I have is that some artists are prolific; loading all of their images may take a long time. If we implement this functionality, we may want to display a warning.
Other than that, it seems like it would be a useful feature. We'll need to think of ways of organizing images by COVERART title, its variants, publication year, etc. Ahasuerus 19:14, 26 October 2018 (EDT)
This was proposed before with a working prototype. See Better way to find varianted or similar cover art and Followup to Better way to find varianted or similar cover art. Stoecker's site is still up and working. The "Dual" mode provides an excellent way to find duplicated / variant covers. -- JLaTondre (talk) 09:28, 27 October 2018 (EDT)
For prolific artists, it may be a possible solution to limit the number of images shown (so you have to fine-tune via advanced search for them). Stonecreek 10:04, 27 October 2018 (EDT)
Pagination would work. Show user configurable number (with some maximum based on performance) of titles in each pane. Allow each pane to be paged through separately. Clicking through vs. scrolling down a continuous page seems a reasonable trade between user ease and performance. -- JLaTondre (talk) 11:12, 27 October 2018 (EDT)
I for one, have also been 'frustrated' with not being able to view all covers of a certain artist, so +1 from me for the show artist cover images FR :) Thanks! MagicUnk 18:15, 27 October 2018 (EDT)
I would love this feature. ···日本穣 · 投稿 · Talk to Nihonjoe 16:11, 30 October 2018 (EDT)
OK, FR 1212 has been created. Ahasuerus 12:45, 3 November 2018 (EDT)

[unindent] If it’s just impossible or too time-consuming, or been tried before and dropped, please don’t bother going into the fine details to explain why. But if one of these vagaries seems technically possible and easy to do, well, why not ? TIA, Linguist 12:30, 26 October 2018 (EDT).

Excellent questions! Ahasuerus 19:14, 26 October 2018 (EDT)

Canonical name change: LeVar Burton

Hi, I want to suggest to suggest to change the name of Levar Burton to LeVar Burton (capital V). That is his proper working name, as seen on all external linked sites. The lower case possibly comes from the cover images of his novel, but those have the name in all caps. The one image that isn't in all caps correctly has the V capitalized. TerokNor 12:41, 30 October 2018 (EDT)

I agree with this. ···日本穣 · 投稿 · Talk to Nihonjoe 15:59, 30 October 2018 (EDT)
Change made. -- JLaTondre (talk) 13:45, 3 November 2018 (EDT)

Merging illustrations

What's the proper procedure for merging this and this without having title variants? user:Rtrace has confirmed they are the same W&B illustration, and the "Tiffany on the Chalk" title is taken from Kidby's website. Circeus 10:37, 1 November 2018 (EDT)

Two options:
* Rename them to have the same title - then merge them. However, if the title of the picture is not in the book, it should not be named that way - we follow the naming inside of the book.
* If the names remain different, they need to be varianted. For art, varianting means: "it is the same picture (more or less - it can have changes in coloring and what's not) but it has a different title in different publications".
Names from the artist's site go into the notes; if the illustration is not named this way IN the book, the title is not used as a title here usually. Being interior art leaves some leeway but... I would still not name it based on a site.
Let me know if any more clarifications are needed or if you need assistance. :) Annie 11:49, 1 November 2018 (EDT)
Please don’t merge or variant those titles. One is an overall interiorart title for an entire book. It contains the other, but also contains the other artwork in the book. --Ron ~ RtraceTalk 13:36, 1 November 2018 (EDT)
They are both identical full-page illustrations. Why shouldn't they be merged? Circeus 13:40, 1 November 2018 (EDT)
Because (looking at Ron's page)the record in Ron's book is NOT JUST for that illustration but for all the internal artwork in the book. Annie 14:44, 1 November 2018 (EDT)
Precisely right. Sorry for the terseness of the previous comment, I was on my cell phone. We have three different ways by which we enter INTERIORART. Unfortunately, we don't have a good way of linking titles for individual artwork to a title that contains multiple artworks. You could certainly add a note on either or both of the title records explaining the relationship. I will note that the individual artwork can be linked with this title. It's a little complicated since one of the pieces is technically a translation. I do question whether the illustration French book really has an English caption. If so, would we still consider the language of that title to be French? Also, does the French book contain only that illustration and omit the headpieces and other decorations? If they are present, there should probably be an overall artwork title for the French translation instead of cataloging only the one illustration. Circeus, do you own or have access to the translation? If so, please verify what artwork exists there and we can figure out how to proceed. Thanks. --Ron ~ RtraceTalk 19:48, 1 November 2018 (EDT)

Advanced Searche changes -- wildcards

The other day the ISFDB server experienced a temporary slowdown. It turns out that it was due to an attempt to retrieve a complete list of ISFDB authors using Advanced Author search. The offending user ran a search on "%", one of our wildcard characters. In order to prevent future performance problems, Advanced Search has been modified to disallow search values which are limited to "%", "*" and "_". Ahasuerus 15:15, 1 November 2018 (EDT)

EditPub and EditTitle -- changing author order

As Template:AllFields:Collaborations states:

  • If a work has multiple authors, it doesn't matter in which order you enter them. The ISFDB does not record author order regardless of how the authors are entered

The order in which authors were entered has always been ignored when filing data into the database. However, Edit Publication and Edit Title used to allow creating submissions which changed author order. It didn't actually do anything when the submission was approved, but it could be misleading.

The software has been updated to make it clear that changing author order doesn't create a meaningful submission. Ahasuerus 21:21, 1 November 2018 (EDT)

Jim McLeod

In the author record for Jim McLeod, is the artist who worked from 1970 to 1988 a different person than the horror reviewer who worked from 2011 to present (and who spells his name "Mcleod")? It seems like a certainty they must be different but I can't actually confirm it. --Vasha (cazadora de tildes) 16:19, 2 November 2018 (EDT)

I think the question should be the other way around. Unless there is something that indicates they are the same (and I'm not seeing it), they should be separated. The time periods and activities are different enough that we shouldn't assume they are the same person. There is nothing about artwork on the provided website link. -- JLaTondre (talk) 16:43, 2 November 2018 (EDT)
I have separated the two. -- JLaTondre (talk) 13:44, 3 November 2018 (EDT)
Thanks, but McLeod (I) should be spelled "Mcleod." --Vasha (cazadora de tildes) 15:46, 3 November 2018 (EDT)
Done. -- JLaTondre (talk) 15:49, 3 November 2018 (EDT)

Canonical name change: John Trevena

I suggest changing John Trevena's canonical name to Ernest G. Henham. It is as commonly found as Trevena (now that I have just added another title as by Henham) and this is the form used in SFE3. --Vasha (cazadora de tildes) 16:57, 2 November 2018 (EDT)

Looks like it was done. ···日本穣 · 投稿 · Talk to Nihonjoe 13:27, 4 November 2018 (EST)

Haunted Houses

Wanted to get some more opinions on a discussion ... it's about a book titled Haunted Houses, for which the publisher's description is "... discusses ten documented cases of ghosts and poltergeists from the past and present and suggests various theories to explain them." I think that it is outside the scope of this DB because it is a nonfiction book about real-life paranormal phenomena; however, the verifier, Auric, argues that it is fiction because "The LC Catalog puts it under 'Ghosts--Juvenile literature'. Also nonfiction is subjective, and depends on whether or not you believe in ghosts." Anyone else? --Vasha (cazadora de tildes) 18:26, 4 November 2018 (EST)

Sorry - jumped in on the conversation instead. The LC (sub)classification of Juvenile literature does not mean fiction. They have biographies sub-classified as such. For this particular title, they have a Dewey Decimal number of 133 which is non-fiction. As to the second argument - is the classification of religion as nonfiction subjective and depends on whether you believe in God? ../Doug H 10:08, 6 November 2018 (EST)
We typically determine whether a work is fiction by examining the way it is presented. Stories like:
  • "I Was Kidnapped and Experimented on by Aliens"
  • "Secrets of Creation as Told by an Angel"
  • "My House Is Haunted"
are considered fiction if they are presented as fictional, i.e. not real, stories. Otherwise they are considered non-fiction. ISFDB:Policy says "Psychic and extrasensory abilities, including but not limited to clairvoyance, levitation, precognition, telekinesis, telepathy and teleportation, when presented as real [are considered speculative fiction]".
We have occasionally run into a couple of issues with this definition. The first one is raised by works which facetiously claim that they are non-fiction. In some cases it's not immediately clear whether the author was being facetious or not. The second one is the publisher using the classic "Truth or Fiction? You Decide!" stunt.
When in doubt, we generally enter the work and add comments. Ahasuerus 12:42, 6 November 2018 (EST)
The phrase that the work "suggests various theories to explain them" does heavily point in the direction of nonfiction: it seems that also non-supernatural explanations are discussed. Stonecreek 00:24, 7 November 2018 (EST)
Are we agreed that this,one should go? --Vasha (cazadora de tildes) 13:29, 17 November 2018 (EST)
Am I misreading something here? The part of the policy, specifically ... when presented as real Ahasuerus cited above actually says to keep it?! MagicUnk 17:42, 17 November 2018 (EST)
The other way around: that's one of the things that is excluded from the DB. --Vasha (cazadora de tildes) 17:54, 17 November 2018 (EST)
No, it is not; it is currently under the inclusion section of the policy. The Haunted Houses case mentioned above is presented as real, so is included. MagicUnk 01:29, 21 November 2018 (EST)
Re-reading the Policy, I think it must be reworded to be clearer; instead of ...when presented as real, it should read ...when presented as if it were real [but is not]. That would correctly convey the intent of the rule, I think. MagicUnk 06:37, 21 November 2018 (EST)

Amazon image cleanup

The post-submission pages associated with New/Add/Clone/Edit Publication submissions have been enhanced. They now display a warning if an Amazon image URL contains additional formatting like ".SY346."

A new cleanup report has been coded and deployed; the data (approximately 1540 publications) will become available tomorrow morning. The report is available to all editors. At this time the report doesn't support the ability to "ignore" records. If we find Amazon URLs that have legitimate "L._" formatting, we will re-evaluate our options. Ahasuerus 18:47, 5 November 2018 (EST)

Jeanne Cook/Gini Koch

Is there some reason why Gini Koch's canonical name is Jeanne Cook? Are we using her real name to avoid having to choose between her pseudonyms? She uses Koch most often by far, and as for it being better known ... two recent publications were billed as "Gini Koch writing as Anita Ensal" and "Gini Koch writing as A. E. Stanton." --Vasha (cazadora de tildes) 17:08, 6 November 2018 (EST)

IIRC, she used a number of pen names in 2009-2011. It wasn't clear which one (if any) would become dominant, so we used "Jeanne Cook" as a stopgap measure. At this point it's abundantly clear that "Gini Koch" has won the race and should be made the canonical name. Ahasuerus 17:56, 6 November 2018 (EST)
All edits have been submitted --Vasha (cazadora de tildes) 22:45, 7 November 2018 (EST)
All approved and I finished the mopping up. Should be all set. Annie 00:03, 8 November 2018 (EST)
Looks good, thanks --Vasha (cazadora de tildes) 00:16, 8 November 2018 (EST)

External ID Search enhancements

The External ID Search has been enhanced to support the following conditions:

  • is exactly
  • contains
  • does not contain
  • starts with
  • does not start with
  • ends with
  • does not end with

The publication table that it generates is currently limited to the first 300 matching publications for performance reasons. Ahasuerus 20:17, 7 November 2018 (EST)

Thanks! That is very useful in chasing identifiers that were set as the wrong type (for the ones that are not just numbers anyway). Annie 17:30, 8 November 2018 (EST)
The search logic has been further enhanced to redirect to the Publication page if only one matching publication record has been found. Ahasuerus 11:42, 14 November 2018 (EST)

Cleanup reports and invalid HTML lists in notes

The cleanup reports which look for bad HTML in notes have been enhanced to search for "li" tags without corresponding "ul"/"ol" tags. The new data will become available tomorrow morning. Ahasuerus 11:03, 8 November 2018 (EST)

Audio books and page counts

It turns out that we have 3K+ audio books whose page count is set to "0". "0" page counts are not displayed on publication pages or in publication tables, so the problem is currently masked.

Would anyone happen to remember if using "0" for audio books was a conscious decision? I can't find anything relevant in our SourceForge archives. Ahasuerus 11:58, 8 November 2018 (EST)

I seem to remember that at least some of the types were producing a bibliographic error when the field was left as 0 - and some people were adding 0 just to make it stop. Not sure how many of them came this way but that may account for some of them. Annie 17:29, 8 November 2018 (EST)

(unindent) Bug 716 has been created to address the fact that "0" page counts are not displayed. SR 144 has been created to blank out audio books' "0" page counts programmatically. Ahasuerus 14:28, 12 November 2018 (EST)

All 2,423 audio books with "0" page counts have had the field blanked out. We also have 1,432 ebooks and 119 webzine issues with "0" page counts. We may want to consider taking the axe to them as well. Ahasuerus 15:59, 14 November 2018 (EST)

Geoff Brown

For a while horror editor and publisher Geoff Brown used the name "G. N. Braun" on the fiction he wrote; we had that as his canonical name, assuming (I suppose) that fiction would be better known. However, the majority of his web presence and interviews are under the name "Geoff Brown," and this year he started republishing the "Braun" fiction as by "Brown" (two stories so far that I know of). Is it time to change his canonical name yet? I actually was thinking that "Brown" should be the canonical name even before he started republishing the stories, and suggested it a couple years ago. --Vasha (cazadora de tildes) 21:46, 8 November 2018 (EST)

Help currently says that "the canonical name is the most recognized name for that author within the genre". I suppose if a fiction author is "most recognized" as an editor (H. L. Gold, Howard Browne, John W. Campbell, etc), the canonical name would be his "editor" name as opposed to the "fiction author" name. We even use R. S. Richardson as the canonical name (as opposed to Philip Latham, the pseudonym that he used for his fiction) because Richardson was somewhat better known for his non-fiction essays in SF magazines.
In this case I think the case for "Geoff Brown" is strong enough to warrant action. Ahasuerus 13:43, 10 November 2018 (EST)

Newford (de Lint) reading order

I'd like to update the reading order for the Newford series to match the author's recommendation. Do I need reach out the PVers for any affected pubs, or can I just update the titles? Thanks TAWeiss 13:00, 10 November 2018 (EST)

Hm, that's a rather tangled web. Since the stories do not need to be read in a particular order (except for the trilogy mentioned by de Lint), one could argue that the publication order is our best bet. Then again, perhaps putting juvenile and young adult books in a separate sub-series may not be a bad idea. Ditto the horror/thriller books published as by "Samuel M. Key" since they are so different. Decision, decisions... Ahasuerus 14:26, 10 November 2018 (EST)
de Lint's recommendation would line up with the publication order, so I think that should be updated. I don't know whether adding a subseries for YA books makes the listing clearer, but I think making sure that the core books are linked makes sense. Based on my reading, "The Wind in his Heart", probably should be removed, and the three missing books from the author's list should be added to the numbered list. TAWeiss 10:23, 11 November 2018 (EST)
I am all for adding the missing books, of course. Re: "The Wind in His Heart" (2017), this Publishers Weekly review mentions "Leah Hardin, a Newford blogger", so I assume that it's at least set in the same universe. Perhaps de Lint hasn't had a chance to update the FAQ yet? (It's a very common problem with these kinds of lists.) Ahasuerus 12:25, 11 November 2018 (EST)

Possible new option for adding translations

As per this discussion on my Talk page, there is interest in simplifying the process of adding translated publications to existing title records. As JLaTondre wrote a couple of days ago:

We are having a lot of translations being entered now. When the translated title doesn't already exist, it is a two step process to add the new book and then variant the translated title to the original. At the title level, it would be nice to have an "Add Translation to This Title" button which would simply be the "Add New Novel" (or whatever one is the equivalent type as the parent) screen, but it would automatically variant the new container title to the original title.

I have poked around a bit and here is what I think. Suppose we have a title like this one and we want to add a translation. Normally, when you click Add Publication to This Title, the following fields are grayed out:

  • Title
  • Transliterated Title(s)
  • Author(s)
  • Pub Type

The proposed option, which we will tentatively call "Add Translated Publication to This Title", will look the same with the following exceptions:

  • title, transliterated title(s), and author(s) will not be grayed out
  • a new drop-down list, "Language", will be added
  • a new field, "title note", will be added. It will be used to capture the name of the translator(s) and/or any other translation-specific information.

The new data entry form will create a submission which, once approved, will create a new title record using the entered title/transliterated title(s)/author(s)/language/title note. It will also turn the newly created title into a variant of the original title. The new title will inherent the values of the "title flags" from the parent title.

Does this sound about right? Ahasuerus 15:26, 10 November 2018 (EST)

Sounds useful, yes. The form will be the same as Add New Publication except for lacking title flags? --Vasha (cazadora de tildes) 16:03, 10 November 2018 (EST)
It will be a cross between Add New Publication and Add Publication to This Title. Unlike the former, there will be no Synopsis field and no Series fields. We could add a "Web Page" multi-field since Web pages are valid for variant titles. Ahasuerus 16:19, 10 November 2018 (EST)
Yes, please :) MagicUnk 16:59, 10 November 2018 (EST)
This field would really be nice to have. Stonecreek 00:18, 11 November 2018 (EST)
That reminds me ... does anyone have bright ideas for how to not display Content field when editing titles except if they're OMNIBUS? I keep pasting web links in that field by mistake ... --Vasha (cazadora de tildes) 18:00, 10 November 2018 (EST)
The larger issue here is that certain title fields only apply to certain title types. Since the Edit Title form lets you change the values of multiple fields, including the title type value, it can result in inconsistencies. Here are some of the ways in which we currently handle these issues:
  • Disallow changing the title type. This is currently done for REVIEWs and INTERVIEWs because you can't easily convert them to other title types.
  • Gray out certain fields based on the title type. This is currently done for the two Series fields when editing CHAPBOOK titles. It's not a great solution since the fields remain grayed out even after changing the title type.
  • Add pop-up validation to prevent editors from creating invalid records. This is what happens when an editor enters a value in the Content field for a non-OMNIBUS title or a "Length" value for a non-SHORTFICTION title.
  • Cleanup reports. Lots and lots of cleanup reports.
One way to handle this issue would be to make the data entry form logic immediately gray out and "ungray out" relevant fields when the value of the Title Type field is changed. Changing the title type from OMNIBUS to something else would blank and gray out the Content field. Changing it to CHAPBOOK would blank and gray out the two Series field. Etc.
The problem with this approach is that blanking no longer relevant fields becomes a problem if the editor decides to change the title type again. The only way to get the zapped data back would be to hit F5, but then the rest of the new data would disappear. This is the reason why I originally decided to use pop-up validation instead of graying/ungraying fields on the fly. If there is a better way to do this, I will be more than happy to implement it! Ahasuerus 12:17, 11 November 2018 (EST)

(unindent) OK, FR 1222 has been created. Ahasuerus 14:23, 12 November 2018 (EST)

Cleanup reports: "HTML in Notes" tweaked

While working on another requested feature, I noticed that some Notes cleanup reports used incompatible lists of disallowed HTML tags. The lists have been consolidated and streamlined based on what's currently stated in Help:Using Templates and HTML in Note Fields#Supported HTML tags.

Once the nightly reports run overnight, the affected reports will include a few new records which mostly use the "small" tag. It's a harmless tag, so if we decide that it's useful, we can trivially add it to the list of supported tags. Ahasuerus 19:47, 10 November 2018 (EST)


Hi Ahasuerus, I just noticed that when I am clicking on the question mark next to the Graphic Format flag of a New Chapbook, I'm redirected to, which is empty, instead of to MagicUnk 06:00, 11 November 2018 (EST)

Fixed -- thanks for identifying the problem! Ahasuerus 10:22, 11 November 2018 (EST)

Mirandese Language

The software has been updated to add support for the Mirandese language. Ahasuerus 10:35, 11 November 2018 (EST)

Post-submission warnings -- HTML in notes and titles

Post-submission pages have been enhanced to display yellow warnings for HTML tags within titles and for invalid/mismatched HTML tags in Notes. The code is brand new and doesn't cover every possible permutation, but it's better than nothing. Ahasuerus 18:56, 11 November 2018 (EST)

Something is off when there is some more complicated HTML. this just decided to show me yellow and it is clean. Another one earlier had a similar problem. The change here is swapping a link with a templated OCLC and I checked 3 times that I did not mess up the only line I edited. Not sure what the parser is catching up on - the report never flagged anything and I do not see a problem either...Annie 19:13, 11 November 2018 (EST)
I think I see what the problem is. Let me see if I can fix it real quick. Ahasuerus 19:52, 11 November 2018 (EST)
If the guess is the "a" tags, this confirms it. No other HTML here... Annie 19:53, 11 November 2018 (EST)
Links and tables, basically. Hopefully the patch that I installed a couple of minutes ago took care of them. Ahasuerus 20:09, 11 November 2018 (EST)
Links don't alert anymore - will keep an eye for other anomalities. Thanks for adding this check! Annie 20:15, 11 November 2018 (EST)
Sure thing. No extra charge for the bugs! Ahasuerus 20:46, 11 November 2018 (EST)

(unindent) When you have a chance, can you see why this did not alert about the missing /a and the missing quotes around the href. These are two of the most common issues with html submissions so it will be great if we can see a warning for them. Annie 01:21, 15 November 2018 (EST)

The invalid HTML report does not catch it either (the missing quotes in href did) - so maybe the missing quotes are throwing off the parser - thus neither the report, nor the new warning system sees it. Annie 01:24, 15 November 2018 (EST)
Any ideas here? Annie 13:48, 16 November 2018 (EST)
Sorry, I missed the original question. I'll take a look when I am feeling better. Ahasuerus 15:05, 16 November 2018 (EST)
Sorry, did not want to nag. Feel better. Annie 15:24, 16 November 2018 (EST)
No problem. At the very least the problem needs to be documented. FR 1225 has been created. Ahasuerus 16:08, 16 November 2018 (EST)


Concerning The Treasure of the Isle of Mist T2215219, in a 1934 edition not yet in the database (AddPub is now in the queue as "to be continued"). Full view of this publication is available at HathiTrust, presumably because there is no 1934 copyright statement for the new illustrations. The text is pre-1923.

I diagnosed "plates included in the pagination" by reference to the numbered pages. For instance the 4-page span pp. 5-8 --two leaves on the usual use of odd and even numbers-- is represented by unnumbered pages that display a small drawing, a caption, a full-page drawing (listed by that caption in "Illustrations" as page 7), and nothing. See page 7 at HathiTrust, for one point of entry. Probably those are two plates, eh?

But another listed illustration corresponds to a span of 3 unnumbered pages only, pp. 171-173, which display small drawing, caption, and full-page drawing. See page 173. Relying on the usual use of odd and even numbers, one page of the text, p. 174, is printed on the back of that full-page drawing. --Pwendt|talk 19:09, 11 November 2018 (EST)

P.S. The Library of Congress has a record of this edition, LCCN: 34-27187, which reports "plates". That means leaves of distinct paper stock, right? And normally the text is printed on other leaves. (I say "normally" but I have previously taken it for granted as universal.) --Pwendt|talk 19:27, 11 November 2018 (EST)

Alternate Titles field

(copied from R&S) ... [Software improvements could help with ongoing issues]

  • Firstly, adding equivalency of capital/small letters in Cyrillic and other alphabets ... (and while you're at it, improved handling of non-Latin-1 characters in the Roman alphabet too).
  • Secondly, adding the ability to ignore punctuation when searching and checking for duplicates.
  • Thirdly (perhaps as a stopgap in place of the other two suggestions), following up on a suggestion which was made some while ago, to add a field for alternate titles which differ only in punctuation or accents; the alternate titles in this field wouldn't be displayed (they wouldn't be mouseover text like transliterations are) but would help with searching.

--Vasha (cazadora de tildes) 15:49, 11 November 2018 (EST)

Re: "adding equivalency of capital/small letters in Cyrillic and other alphabets", it's certainly desirable and important. However, it's not really "adding functionality", it's "upgrading/replacing the database engine". Think of it as replacing a gasoline engine with a diesel engine: doable but time-consuming and but has all kinds of ramifications for the vehicle. Given my other current responsibilities (Fixer, maintenance, e-mail communications with 3rd parties like SFE3 and MIT, Wiki, etc) and my less than stellar health/energy/ability to learn new things these days, big projects like that are a steep hill to climb. We could really use another developer or two. During the summer I helped a volunteer set up a separate development server, but I haven't heard back from him in a few months. I have other prospects as well, but nothing definite at the moment. Of course, a number of our active editors have development backgrounds, but for some reason they seem to be unwilling to quit their day jobs and concentrate on ISFDB development. Most peculiar! (Fixer tells me that it may have something to do with the rumor that humans like to eat.)
Re: "the ability to ignore punctuation when searching and checking for duplicates", the main Duplicate Finder has three modes: Exact, Similar and Aggressive. The last two ignore punctuation. On the searching side, I experimented with different approaches a few months ago, but it turned out to be significantly more complicated that I had expected. Apparently, the guys at Google are well paid for a reason... Ahasuerus 16:30, 12 November 2018 (EST)
Yes, I remember you've said before that these things aren't really feasible without some change in circumstances (like additional developers). Sorry for bringing them up again. But since real improvements are far off, what do people think of adding a field for this sort of variant titles? We are currently using the transliteration field for the purpose, but it's not the best practice to mix two kinds of data in the same field. --Vasha (cazadora de tildes) 16:49, 12 November 2018 (EST)
Agree re: "it's not the best practice to mix two kinds of data in the same field". The issue has been raised in the past, but no FR has been created (that I recall.) The proposed functionality, as I understand it, would be a subset of the functionality supported by Field 246, "Varying Form of Title", which exists to record "alternative form[s] of the title" in the MARC 21 standard. The linked Web page includes various examples. If you would like to pursue this line of thought, we may want to move the discussion to the Community Portal. Ahasuerus 20:39, 12 November 2018 (EST)

(unindent) The proposal is to add a field for the purpose of collecting together minor variations in the title (or other author name, etc.) which currently cause the software to not recognize them as the same title (author). Namely, things like non-Latin1 characters (people need to be able to find Helen Oyeyemi's story "Dornička and the St. Martin's Day Goose" even if they type "Dornicka"), and minor differences in punctuation like whether there is or is not an Oxford comma. There are also existing instances in this database of the Transliterated Title field being used to store other types of variation that are on the MARC 21 page Ahasuerus linked, such as entering "One Hundred Cats" as an alternate to "100 Cats." The proposed new field would never be visible to users (it wouldn't be mouseover text like transliterations are), but it would be used by the software in searching.

This would be just an ad-hoc thing as a stopgap until (at whatever future time) the software is improved. People would simply enter whatever variants they can think of. We have already put some of that into the transliteration field; it would be a moderate-size cleanup project to move it to the new field and leave Transliterated Title for just transliterations from one alphabet to another. --Vasha (cazadora de tildes) 21:45, 12 November 2018 (EST)

Easier solution is to use Google. Add a new search option on the Advanced Search that uses a Google search with predefined syntax that limits the search to ISFDB and with specific words (Title, Publication, Summary Bibliography, Publication, etc.) in the page title. For the Dornicka example, intitle:title Dornicka will search only ISFDB for pages that have Title in their title (i.e. title records), and matches Dornicka which correctly returns "Dornička and the St. Martin's Day Goose" (try it). It would consist of a single pull down to select page type and a text box. That would be a lot easier than adding new fields (which need to be added to the database, multiple forms, search options, etc.) and also then need to be populated. Search engines are great at fuzzy matches so let them do their thing vs. recreating it in a much less ideal way. It will search the whole page, not just a particular field, which can either be a downside or a plus depending on your goal. -- JLaTondre (talk) 07:35, 13 November 2018 (EST)
It would be easy to add a "Google Search" option to Advanced Search. We could even add a context-sensitive "Google Search" check mark to the main search box. (The reason it would have to be context-sensitive is because a Google search on "Year of Title = 1872" wouldn't work too well.)
However, keep in mind that Google's data is typically a few weeks behind, so it won't find any recently added/changed data.
I am thinking that the low-hanging fruit would be to add a "Google Search" section to Advanced Search, which can be done quickly, and see what happens. Ahasuerus 08:26, 13 November 2018 (EST)
Yes, Google search isn't the ideal solution. However, I think it's better than the suggested interim solution given the trade between work & benefit. Though my over all preference would be doing neither since there is other work I'd personally rate higher. So maybe I'm biased. ;-) -- JLaTondre (talk) 11:35, 13 November 2018 (EST)
That'd help. But would it allow the stuff that doesn't belong in the transliteration field to be removed, or would we still need that? There's an existing cleanup report that mandates entering an alternative to non-Latin1 characters --Vasha (cazadora de tildes) 12:26, 13 November 2018 (EST)
Well, if you work with Cyrillic titles, you may have a different bias - try to look for an author called Вежинов and then вежинов. :) For example. Now think about how often people hit caps lock or shift by mistake :) Another option is to use the transliterated fields to contain a "lower case only" version of the name amongst the other transliterations and add an explanation to the advanced search (and on the result screens) on how to search in case you cannot find what you are looking for). Thus NO real work (besides a few comments in the search pages) as we already search the transliterations by default. That would be similar to transliterating the kanji in kana for Japanese. Not elegant but... good enough stopgap until we can swap the encoding. And once it is swapped one day, deleting these will be easy (as they will match without case to the main title). And it is similar to the whole alternative title thing... (at least for the search problems) minus the work. Plus there is a case to be made that going to all smalls is a type of transliteration (from an alphabet of A-Za-z to one with a-z)  :) Annie 12:32, 13 November 2018 (EST)
Uh, no, that is not a transliteration. Someday (hopefully) we are going to have a real solution to the problem of fuzzy searches/capitals in Cyrillic/etc. and then the transliteration field will just be for one alphabet to another (one writing system to another, in the case of kanji-to-hiragana). Why shouldn't we start now with the process of cleaning up that field, putting everything that is not a transliteration into a different field? We have thousands of titles currently where the lowercase version or non-latin1 character or whatever is in the transliteration field, and it would take a few days to go through and move them all; in five years we will have many more thousands—why not enter them into a different field to start with, instead of putting them in the transliteration field where they will eventually have to be removed? --Vasha (cazadora de tildes) 13:13, 13 November 2018 (EST)
Because I would rather have non-transliteration there than spend 2 (or 5) more years waiting for this DB to become even remotely usable for the titles in my native language. And as they will be exact matches (minus letter size), they will be easy to remove when we have that fixed - so we are not facing a long project pulling them out. Let's be realistic here, shall we? Great ideas and what's not is great BUT spending time to build a solution that will be obsolete when we change encoding is worse than dealing with some additional values in some fields. And dumping all kinds of stuff in a new field would not solve the problem - it will just move it to a new field (what goes there? Small letters ones, kana ones for Japanese? Something else? Everything that is not a transliteration?) Call me pragmatic if you want but I would rather not stress the single developer with something that we live without and where we have a soft solution that does not really degrade the data. Annie 13:29, 13 November 2018 (EST)
"We have thousands of titles currently where the lowercase version or non-latin1 character or whatever is in the transliteration field" - huh? Noone had added "lowercase" specifically anywhere so I am not sure what you are talking about? Annie 13:29, 13 November 2018 (EST)
"Transliteration" has a pretty concrete definition. It is taking a word written in one writing system and coming up with an equivalent in a different writing system. Yes, writing the sounds represented by a kanji character as hiragana is a type of transliteration. I am arguing that the Transliterated Title field should only be used for transliterations in this sense. Up to now, we have needed a place to store ad-hoc typographic information like the fact that people may search for "č" by typing "c" or the fact that French "œ" is a typographic variant of "oe," and we have put it into the transliteration field, but it isn't the same type of data and shouldn't go there. --Vasha (cazadora de tildes) 13:40, 13 November 2018 (EST)
Your claim is that NOW we have "small letters" being added to fields - see what I cited from your post. That's the part I am asking about. Because it is not true - we do not use the field this way now. Even if that would have made the DB usable. I know what transliteration is - both from the Linguistics side and from the Math/IT side. As for what is a valid transliteration - A-Zaz -> a-z is writing the same title in a new "set of characters". Not in the linguistics sense but then a lot of things are not. And œ/oe and Б/б are comparable. Just because the letters set is in the same alphabet does not make it less of a transliteration. Technically speaking. :) And again - moving all that "stuff" to a new field does not solve the issue - it just moves it to a new field. Or are we going to keep adding fields ad-infinitum? Annie 14:44, 13 November 2018 (EST)
But anyway - the point I am trying to make is that building a solution that will be obsolete soon does not make sense - when we can just reuse what we have. It does not matter if it is "clean", in both cases we will need to deal with it once the real solution is in place. Add effort, time to execute and all that and as much as I like clean solutions, I would take any solution at this point. Annie 14:56, 13 November 2018 (EST)

Types of Alternate Titles/Values

Let me take a step back and try to list the different types of "alternate titles/values" that we are discussing here. (I prefer "values" to "titles" because the discussion also includes authors, publishers, etc.)

First, here are the scenarios that are currently supported by our implementation of "transliterated values":

  • Romanized versions of non-Latin values. The current implementation supports multiple versions per original value, e.g. "Arifureta Shokugyō de Sekai Saikyō 1" as well as "Arifureta Shokugyou de Sekai Saikyou 1" for "ありふれた職業で世界最強 1".
  • For languages which use multiple alphabets/scripts/writing systems, version(s) of the original title which use alternate systems, e.g. "ありふれたしょくぎょうでせかいさいきょう 1" for "ありふれた職業で世界最強 1".
  • English versions of Latin titles which use non-English letters, e.g. "Dornicka" for "Dornička" and typographic variants like "œ"/"oe"

Next, here are the new types of alternate values which are being proposed, either to be entered in the requested new field or as additions to the list above:

  • Lower case versions of non-Latin values to help with searches
  • Alternative forms of the original value like "One Hundred Cats" as an alternate to "100 Cats". It could include other alternative values like the titles found on book covers and spines which we currently enter in Notes (or omit.)

Re: lower case versions of non-Latin values, I think it will only get us so far whether we enter them in the existing Transliterated Values fields or in the requested new field. Adding "павел вежинов" to "Павел Вежинов" won't help users who type "ПАВЕЛ ВЕЖИНОВ". Without full Unicode support, it will remain a band-aid.

Re: alternative values like "One Hundred Cats", it's been discussed a few times. I don't recall any objections, but it appeared to be a low priority. Also, it will remain a valid separate request even after the upgrade to Unicode. If we can reach consensus re: its desirability, I would be in favor of adding it as a separate FR.

Am I missing anything? Ahasuerus 17:05, 13 November 2018 (EST)

Punctuation is mIssing. Right now typing "X - Y" into the search box won't find "X—Y" and vice versa, nor will "X, Y, and Z" match "X, Y and Z." Plus we had a debate a while ago as to whether it was acceptable to use the transliteration field to enter "X and Y" as an alternative if "X & Y" is printed in the book (who can remember which form to search for?). Finally, I don't agree that typographic matters like c/č and œ/oe properly belong in the transliteration field. --Vasha (cazadora de tildes) 17:25, 13 November 2018 (EST)
So what do you call the č -> c (or ch) transition? It is converting Unicode/ to Latin1 which is the definition of transliteration in the IT world. Looking at the linguistics level, it is a transliteration between two Latin standards (in the same way in which Э э get changed to an existing letter in the alphabets that do not have it; or й between the Cyrillic standards)... But the main question still stand - how adding a new field that contains all that funny stuff will be helpful at all and not just moving the problem from one field to another. Just so it is not in the transliterated field? What is the difference? Maybe we should revisit why we have transliterations to start with - assisting reading from non-native editors and users and facilitating search for users that do not have the proper keyboard to create the special characters (or copying from a source that does not have the correct characters when searching). Or is the second not part of why we have the field anymore? :) Annie 17:43, 13 November 2018 (EST)

(Unindent) OK, instead of arguing about what is or is not a transliteration, and what can or can not go in the "Transliterated Title" Field, how about we rename that field to "Alternate Form of Title"? And agree that you can enter anything into that field if you think it'll be helpful? That'll make sense of all the diverse stuff that already is in it. --Vasha (cazadora de tildes) 18:09, 13 November 2018 (EST)

I think the first step would be to update Help with a list of everything that this field currently supports. After all, there are things that are disallowed at this time, e.g. alternative forms of the main title like the "One Hundred Cats" example above and transliterations that use non-Latin non-native alphabets/scripts. Having the current practices explained in one place (a new Help template, I assume) would get all of us on the same page. With the current rules codified, we would be in a better position to decide whether to:
  • rename the field
  • expand its remit
  • do something else
Ahasuerus 12:49, 14 November 2018 (EST)
Results of a survey of current ways this field is used with titles whose language is English--Besides giving alternatives for non-Latin1 characters, there are the following sorts of uses:
1. Giving text equivalents of titles with symbolical or mathematical elements in them. There are about 50 of these I think; here are a selection:
Rendezvous 10¹⁰   |   Rendezvous 10 to the power 10
   |   e^h
Golem¹⁰⁰   |   Golem 100
⁵Limericks   |   5 Limericks
X ≠ Y   |   X does not equal Y
∞°   |   Infinity Degrees
The World of Ā   |   The World of A   |   The World of Null-A
fan•dom (fan´ dəm) n. a way of life   |   fandom (fandum) n. a way of life
&#x25CD;   |   "Circle with Vertical Fill" Hex code
   |   Cancer
*   |   asterisk   |   star
█████   |   {black bar}   |   [redacted]   |   redacted
Press Enter ▮   |   Press Enter []
<3/</3   |   less than three slash less than slash three
Foreword ((1⁴+2⁴+3⁴+4⁴+5⁴)+6⁴+7⁴)   |   Foreword ((1(to the 4th degree)+2(to the 4th degree)+3(to the 4th degree)+4(to the 4th degree)+5(to the 4th degree))+6(to the 4th degree)+7(to the 4th degree))
2. Giving "and" as an equivalent to &. Done 33 times with the "and" in the main title, & in the transliteration; twice the other way around.
3. Giving "plain" equivalents of titles that are written oddly. For example,
Channel Sk1n   |   Channel Skin
βoyfriend   |   Boyfriend
4. Multiple attempts at writing titles that cannot be entered the way they are in the book. Here is one I did myself: I represented "How Can I Help Hurt You?" as "How Can I Hurt You?" and "How Can I Help Hurt You?"
5. Punctuation variants (these are pretty rare). A selection of examples:
Perce Rock ▬ First Sighting   |   Perce Rock — First Sighting   |   Perce Rock - First Sighting
Little Green Men—Attack!   |   Little Green Men Attack
Never Fear: The Apocalypse   |   Never Fear—The Apocalypse
Interstellar Navigation, or Getting Where You Want to Go and Back Again (in One Piece)      |      Interstellar Navigation; or, Getting Where You Want to Go and Back Again (in One Piece)
6. Just plain alternate titles.
SciFan™ Magazine - 2017   |   SciFan Magazine - 2017
[a cover art title] Jump Point, Issue 02.03   |   Warned
The first of these categories, at least, seems pretty firmly within the existing mission of the field (the others may be extensions of the mission, and number 6 flat-out wrong). But "Alternate Writing of Title" or some such name seems to describe those text-equivalents better than "Transliteration." --Vasha (cazadora de tildes) 15:26, 14 November 2018 (EST)
Why isn't "™" in the first category? This is a special symbol, not two letters with weird formatting (in that writing anyway). Not much different from some of the others in category 1. I would not call that alternative writing - it contains a symbol that people may not be able to create... Just because it looks like letters does not make it letters really - not in a title. Annie 15:46, 14 November 2018 (EST)
Because SciFan Magazine is sometimes written with the TM and sometimes without, and I think this was intended as a way of putting both names in the same record. We should figure out which is the "real" title and/or make them variants of each other. (Not that easy because SciFan Magazine is now defunct and out of print, but ...) --Vasha (cazadora de tildes) 16:01, 14 November 2018 (EST)
It occurs to me: "and" is a text-equivalent of "&" so that one, at least, makes sense in the existing conception of the field. --Vasha (cazadora de tildes) 16:20, 14 November 2018 (EST)

(unindent) Attempt at codifying the use of this field (whatever it's called). Currently, it is chiefly for: 1. Transliterations from one writing system to another. 2. Providing Latin1 alternatives to non-Latin1 characters. 3. Spelling out mathematical expressions and symbols in words.

Proposal: As a logical extension of use no. 3, I would like it to be specified that it's acceptable use this field to spell out "&" as "and." Second proposal: spelling out numbers in words; this is also a logical extension of use no. 3.

Other possible uses: spelling out abbreviations? (e.g. vs./versus)? I'm undecided but I think maybe not.

We also have a few quirky miscellaneous uses at present, like the strikethrough example and the Channel Sk1n/Channel Skin example above. There are only a few of these, I don't see a better way to handle them, and as far as I'm concerned they can be left as is, ignored & not mentioned in the codfication of the uses of the field.

It seems that this field should NOT be used for variant punctuation. The proposed Google search will take care of it instead (and much better).

Any thoughts on additions/subtractions to this list of uses? I think we are almost ready to write up a description of the field, and then we can debate its name. --Vasha (cazadora de tildes) 01:23, 16 November 2018 (EST)

Narrator Template

Can we add a Narrator template for publication notes? That will make it easier to find the books we have that are narrated/read by a certain person (and one day when we have "non-authors connected to books" fields, we can migrate easily. Annie 22:50, 12 November 2018 (EST)

It would be easy to add a new template for narrators assuming that the functionality is similar to that of the "Translator" template. Ahasuerus 08:53, 13 November 2018 (EST)
Yep, same idea. :) Annie 12:13, 13 November 2018 (EST)
What should we call it then? "Narrator"? Something shorter along the lines of "Tr"? Ahasuerus 15:35, 13 November 2018 (EST)
Narrator sounds good to me. Tr made sense but I cannot figure out how to make Narrator shorter without making it too cryptic :) "Reader" also works for me - although it should still be "Narrated by X" when on the page. Or maybe "Narrated/Read by X"... Annie 15:39, 13 November 2018 (EST)
Too long to type. Why not {{narr|...}}? MagicUnk 16:34, 13 November 2018 (EST)
Too cryptic if you ask me... But I can live with narr. Or maybe "read"? Annie 16:50, 13 November 2018 (EST)
Wellll, you could say that of "Tr" too. But once you know what it is, you won't forget. Narr has an advantage over read in that narr == narrated is easier to remember than read == narrator. MagicUnk 17:19, 13 November 2018 (EST)
"Tr. by X" is a standard bibliographical entry though :) Older books called those "readers", now the modern term is "narrator" although some books still say "read by". So they are interchangeable. So for some people the term is reader and not narrator so "narr" will be absolutely undecipherable. I can work with either - and we can always change if needed Annie 17:30, 13 November 2018 (EST)
I expect that "read" would be less intuitive than "narrator". Also, since I don't use audio books, I would probably find it hard to remember that "narr" stands for "narrator", but perhaps I would get used to it. Ahasuerus 12:33, 14 November 2018 (EST)
I still think that the one that will the least confusing is "Narrator" :) Annie 13:48, 14 November 2018 (EST)
That would be fine by me. Ahasuerus 15:00, 14 November 2018 (EST)
Sure, can live with that :) MagicUnk 16:59, 14 November 2018 (EST)

Narrator Template - Outcome

FR 1224 has been created. Ahasuerus 10:07, 15 November 2018 (EST)

Length for Audiobooks

On a related note, how long a book runs is comparable to page numbers. So should we add a new field to collect this information (audiobooks are more and more popular) or should we start using the "pages" field instead (as these will never have pages). I am more inclined to go for a new field (two separate pieces of data in the same field is a bad idea) but in this case as a book is either a paper one or an audio one, they are separate enough (and ebooks stay with the current policy of "no number of pages")Annie 22:50, 12 November 2018 (EST)

If a new field is added, it would be best if the software was smart enough to only display the correct field for the type of pub (i.e. physical books should page number, ebooks show nothing, and audio books show length) instead of always showing them. Or at least only make the correct one editable. Requires the edit form to be a bit smart as have to update the display when the format is changed while editing. -- JLaTondre (talk) 07:18, 13 November 2018 (EST)
I discussed some of the issues with dynamically changing the data based on the title/publication type here. Ahasuerus 08:33, 13 November 2018 (EST)
Field state (active/inactive, displayed/hidden) can be changed dynamically via JavaScript. Here is an example that displays a field when one option is chosen but not another. The value is not lost when hidden (in the example, change it to "Business use", enter text, change it to a different state, and the change it back). On the back-end, the submission logic would need to handle the fact there is a no longer needed value and toss it out. -- JLaTondre (talk) 09:18, 13 November 2018 (EST)
How about the same logic we use for "series" in variants? Annie 12:13, 13 November 2018 (EST)
That doesn't work the reasons Ahasuerus laid out in his above link. It works for series because you cannot make a variant a non-variant from the title edit screen. -- JLaTondre (talk) 12:45, 13 November 2018 (EST)
Yeah, missed that one when reading this morning. Oh well... I am not sure what is the problem with just having both and having editors just be careful plus a nightly report that finds values in the wrong field. Considering all the other problematic fields, that one is not even that challenging. I would love a software solution but if there isn't one that works across browsers and what's not, we can live with it :) Annie 14:47, 13 November 2018 (EST)
We could add pop-up validation that would disallow "length" values for non-audio formats, but first we would have to decide what to do with combined "paperback+CD" publications. Ahasuerus 08:33, 13 November 2018 (EST)
Any thoughts re: "paperback+audio" publications? I believe I have only one in my collection, but they have apparently become more popular lately. Their records should presumably allow both types of values. Ahasuerus 15:41, 13 November 2018 (EST)
Allow both fields to be populated for that case specifically. That should not be a problem, right? Annie 16:30, 13 November 2018 (EST)
There's an issue with adding fields at the front end: clutters the screen, losing oversight. Therefore, "smart" forms are the way to go. MagicUnk 16:55, 13 November 2018 (EST)
This is the part that I am not sure about. Back when we added context-sensitive drop-down lists to the Advanced Search page, some users commented that they didn't understand why values were changing as if by magic. I am concerned that dynamically adding and deleting fields based on the values of certain other fields (like the publication type field) would be even more confusing. Ahasuerus 12:40, 14 November 2018 (EST)
Really? Once upon a time I had something done very similar with an application I defined the functionality for (ie dynamically updating labels dependent on certain type values), and no-one ever complained that was confusing. Au contraire, I definitely got the impression they really ignored it altogether... MagicUnk 16:54, 14 November 2018 (EST)
A lot can depend on the user community, including things like their computer savvy, whether they are occasional users or regular users, etc. Ahasuerus 10:06, 15 November 2018 (EST)
(Adding more fields to the database isn't an issue. In fact, on DB level fields should never be used for multiple purposes). There's another way of dealing with using a single input field for two different value types: change the label only, and when saving, the backend logic determines in which field to save the entered data, dependent on title type. Only one field needed, so no keeping track of previously-entered data when switching type.That approach doesn't support the pb+audio though, but it might be useful approach somewhere else... MagicUnk 16:55, 13 November 2018 (EST)
Which is where I started - reuse the field we have now. Technically pb+audio is not different from a boxset where we do 300+300+300 for example... as long as we know what is first :) New field will make it less confusing for new editors BUT more convoluted for us (what do we show on pub lists under a title for example)? Annie 17:27, 13 November 2018 (EST)
Not sure we were actually saying the same; there's a distinction to be made between adding additional fields on the forms (and hence to the DB as well) - which is what you were proposing if I understood correctly?, as opposed to keeping the UI slick, keep changes and additions to a bare minimum, and only expanding the DB tables with additional attributes. MagicUnk 16:57, 14 November 2018 (EST)
My initial note had two proposals - keep one field for both (type determines what it means) or add a new one. How the DB is designed behind that is irrelevant really - and if we have a single field, doing separate DB fields and from there separate search options will be confusing (and can have performance considerations if someone tries to do a query weirdly) so if we stay in one field, we should just stay in one field if you ask me. :) Annie 19:39, 14 November 2018 (EST)

Changing data entry forms dynamically -- options

I have been thinking about JLaTondre's response above and, more generally, the options that we have when data entry forms end up with internally inconsistent data: CHAPBOOKs with Series data, non-OMNIBUS titles with "Content" data, and so on.

I will first list the options that I was aware of when I was writing this comment:

  1. Disallow changing the values of certain key fields to avoid inconsistencies. This is currently done in Edit Title for REVIEWs and INTERVIEWs: you can't easily convert them to other title types.
  2. Gray out certain fields based on changes to key fields like "title type". This is currently done for the two Series fields when editing CHAPBOOK titles. It's not a great solution since the fields remain grayed out even after changing the title type.
  3. Add pop-up validation to prevent editors from creating invalid records. This is what happens when an editor enters a value in the Content field for a non-OMNIBUS title or a "Length" value for a non-SHORTFICTION title.
  4. Dynamically gray out and blank affected fields whenever changes to other fields make them invalid, e.g. Series fields for CHAPBOOK titles. The problem with this approach is that blanking no longer relevant fields becomes a problem if the changes that prompted the blanking are reverted.
  5. Cleanup reports. Lots and lots of cleanup reports.

In addition, we have the following options when "key" values are changed:

  1. Dynamically gray out the affected fields, but do not delete their data. That way if the changes to "key" fields are reverted, "ungraying" the affected fields will restore their data. The problem with this approach is that it may confuse editors who won't understand what "grayed out" data means and whether it will be filed into the database upon submission approval.
  2. Make the affected fields invisible; if the "key" changes are reverted, make them visible again. Would new editors find disappearing fields confusing?
  3. Dynamically gray out the affected fields, delete their data and save it within the browser (probably using a hidden field, which is what we do in Advanced Search.) If the "key" changes are reverted, use the saved data to restore the affected fields' values.

From a purely technical perspective, it's all doable. Functionally, I think I prefer pop-up validation to the "gray-out"/"invisible" options. I suspect that (but can't be sure) changing the form layout and/or the field status dynamically has the potential to confuse new editors. Ahasuerus 16:19, 13 November 2018 (EST)

I am fine with popups. Annie 16:48, 13 November 2018 (EST)

Autobiographical titles acquisition

For our spec-fic authors, which of their publications about themselves should we include in the database? Any threshold on the author should be lower than that certain threshold (ISFDB:Policy#Included, point 4) over which all publications should be included.

For instance, in 1936 newspapers I find coverage of the new book A Long Retrospect as the autobiography of F. Anstey --see LCCN: 36-21029 and ASIN: B000857ECY at Amazon UK. And I find notice that Laurence Housman has nearly completed his own autobiography --not pursued.

One issue here is routine acquisition from secondary sources, as many works mentioned in SFE3 and The Encyclopedia of Fantasy biographical entries are routinely added. Knowing that the book is by Anstey about Anstey, say. Let me stop here. --Pwendt|talk 16:44, 13 November 2018 (EST)

I don't think we have a separate threshold for autobiographies of primarily non-genre authors. That said, as a collector of all things Anstey, I understand where you are coming from. He wrote a fair amount of notable speculative fiction starting with Vice Versa, a minor classic of the genre. Tourmalin's Time Cheques was an early time travel novel which preceded Wells's The Time Machine, etc. Even though we currently don't include his non-genre works, I agree that his autobiography should be included.
At the same time, I am not really sure how we could address this issue at the Policy level. Adding a new threshold for autobiographies would likely only complicate things, especially considering the nebulous nature of the current "certain threshold" for non-genre works. Perhaps we could include autobiographies as "books ABOUT speculative fiction"? Ahasuerus 12:26, 14 November 2018 (EST)

Question about Connection Security

HELP! I have joined ISFDB only on a temp basis because "The Connection is not Secure" is the WARNING I get when entering my Password. I tried using https:// before the URL, but this fails. And I searched high and low for a Contact Us address, but there is none! Only way to get this message to you was to join as a temporary member, pending improved security. Please advise, before the Russians start messing with my account... —The preceding unsigned comment was added by Temp Insecure‎ (talkcontribs) .

Answered on the user's Talk page. Ahasuerus 19:35, 13 November 2018 (EST)

Author names alphabetized

The way co-author names are displayed has been changed. In the past their order was random. Now they are displayed alphabetically based on their respective directory entries (typically family names) and the working names. If you come across any discrepancies, please post them here. Ahasuerus 20:33, 13 November 2018 (EST)

Title case cleanup - how?

(copied over from R&S): For the Dutch titles - and likely for other languages too - almost all titles hitherto entered in the DB follow the English capitalization rules. Now that we have made it clear language-specific capitalization rules are to be followed, titles need to be updated. What would be the best approach? Can we automate/manual excercise, cleanup reports,...? MagicUnk 17:30, 14 November 2018 (EST)

It is possible to create language-specific cleanup reports to look for titles with second/third/etc words capitalized. I expect that there will be a lot of false positives, so they'll need the "ignore" functionality from the get-go. Ahasuerus 18:29, 14 November 2018 (EST)
Would it work having a nightly job that automatically converts pub titles to the title title's case? Would be great not having to go through both title and pub titles. MagicUnk 02:21, 15 November 2018 (EST)
Originally, there was no requirement for publication titles to match the titles of their respective "reference titles". In fact, we had somewhat different data entry rules for them. However, the rules have been converging over the last few years. We also have a cleanup report which looks for significant discrepancies between publication titles and their reference titles. At the rate things are going, we may want to consider enforcing consistency in the foreseeable future. For now, though, they can be different.
In addition, any kind of automated processing that changes ISFDB records without human supervision is potentially dangerous. We don't have anything like that in place at this time. Ahasuerus 09:56, 15 November 2018 (EST)
As I recall, French and Russian titles have been using "sentence case" for a long time, so they should be in pretty good shape. I am not sure about other languages. I guess we could start by contacting the editors who have been working on major European languages to get a better idea of what the scope of the project(s) is likely to be. (And I see that Annie has already made a similar suggestion on the R&S page.) Ahasuerus 18:29, 14 November 2018 (EST)
From my OCLC cleanup and the language assignment one before that, French, German and Russian are indeed in a relatively good shape. Dutch is not looking too bad although it is a bit worse than the other 3 - there are a lot of titles with the wrong capitalization but from what I had seen a lot more that are added correctly. Spanish is a mixed bag (although I had seen a lot of updates going through), Italian is right there with it and Portuguese will give us a headache. The Western Slavic languages and Hungarian are mostly in the proper sentence case; so are Serbian, Romanian, Finnish and the Scandinavian ones. Bulgarian is clean :). Greek may be a bit of a challenge; the smaller ones should be easy enough to vet even if we go title by title. So as long as we decide on the rules, we may learn more.
Re. Dutch not too bad: I'm afraid that's not true. I did a search, and for the first few hundred results, all needed correction to sentence case.
The first hundred are stories with special characters and what's not which are relatively old records. It gets a lot better downstream - somewhere along the line Dutch editors started using the proper case. Although due to the volume of records, there may be more than expected... :) although looking a bit more into these, Dutch may need reclassification indeed - not sure which language I was thinking of. Oh well. That will be a very long project. Annie 02:43, 15 November 2018 (EST)
But point still stands - we need first to agree on the rules for a language before we start changing things in that language. Annie 18:54, 14 November 2018 (EST)
I'm confused?! Didn't we already agree on the case rule for Dutch? - true, not yet for punctuation but that shouldn't prevent us from cleaning up the ones that have no issue with punctuation. Or am I missing something here? MagicUnk 02:12, 15 November 2018 (EST)
You telling us that is the rules on a page is not an agreement - especially in a language we have multiple editors. Get the other editors to agree, we get closer. And when the official rules are changed, it is considered agreed on. Annie 02:43, 15 November 2018 (EST)
Btw, I'm asking because I'm going through a lot of Dutch titles atm. MagicUnk 02:18, 15 November 2018 (EST)
Then leave a few messages around so we can get the rules locked down? Annie 02:43, 15 November 2018 (EST)
Yes, let's get those rules locked down. We have agreed to language-specific capitalization, but we haven't touched punctuation. Seems like we really ought to talk about punctuation before starting cleanup so as not to have to make multiple passes through the same records?
As for the Spanish data, there are quite a few Spanish records that were imported by machine in the early days of automated imports and were never cleaned up, and they're often in bad shape in every field. I fix them when I see them but I haven't had time to go after them systematically. --Vasha (cazadora de tildes) 19:02, 14 November 2018 (EST)
Not just Spanish - a few more languages seem to have been imported the same way. Spanish is just the biggest offender. Plus we also have the translators to sort out so we can do 3 in 1 while editing for case, punctuation, subtitles and so on anyway. :)
So Title Regularization invites everyone to contribute so we can start clearing languages. Annie 19:10, 14 November 2018 (EST)

"0" Page Counts - Software Changes; Ebooks

While reading the code earlier today I finally recalled why we had special display logic for "0" page counts. Back in 2006-2009, when ebooks and audio books were not as common as they are today, we tried to come up with a standard for entering them. Both "0" and "unpaginated" were proposed as the preferred way of entering their page counts and the software was updated accordingly. That semi-standard was abandoned years ago and is no longer mentioned in Help.

Based on my findings, I have updated the software not to do any kind of special processing for "0" and "unpaginated" page counts. As of 15 minutes ago, the software simply displays whatever is in the "Pages" field, assuming that it's not empty. I have also removed "0" from the page count fields of all ebooks. Fewer than 2% were affected.

This leaves us with 119 webzines and 9 "other" publications which still use "0" as their page count. I left them alone for now in case anybody wants to look into them. Ahasuerus 17:52, 14 November 2018 (EST)

I will check the "other" ones and update as necessarily. I think that getting the webzines cleaned should not be a problem - they are not different either...
Any chance of adding the nice yellow warning when someone tries to add pages on non-text material? Annie 17:58, 14 November 2018 (EST)
Potential problem: theoretically ebooks don't have pages; however, PDFs, which do have pages, are lumped in with other ebooks --Vasha (cazadora de tildes) 18:19, 14 November 2018 (EST)
We can exclude ebooks for now - I am more concerned about audiobooks and the like at the moment. However - even for PDFs, our rules say not to record page. So... technically those should be empty. If we want to separate the PDFs, we need a separate discussion. But that opens the Pandora box of the old Fictionwise titles (remember those?) that you could download in more than one format, one of them being PDF - and recording all formats as separate books did not make sense. Thinking about that, there are a few publishers like that nowadays as well... Annie 18:26, 14 November 2018 (EST)
Although I unfortunately can't recall exactly what it was, I know I saw one book which was offered in PDF format with illustrations or ePub/mobi without illustrations. Really, PDFs aren't quite the same thing as other ebooks (more similar to a printed book in some ways). But I don't want to start a discussion about that on top of the other 20 ongoing discussions. --Vasha (cazadora de tildes) 18:43, 14 November 2018 (EST)
For some of them. But for a lot of publishers, they are basically the same - just a new format... When there are illustrations in one and not in the other, they should be separate records anyway. Although the current e-book formats support images so... the differences will be less and less. And converting between the formats is trivial. I do not dispute that there are e-books that have pages (from scanned copies of paper books to proper PDFs), we need to decide what we want to do about them before we start adding page numbers (as the current rules do not make a difference). Annie 18:59, 14 November 2018 (EST)
Keep in mind that a yellow warning is just that -- a warning that tells the approving moderator to do more digging. For example, Fixer submissions without a publisher generate warnings, but in many cases they are OK "as is". Ahasuerus 10:00, 15 November 2018 (EST)

SFBC question

I picked up an SFBC copy of Rift in the Sky. It has an SFBC number, 1275245, on the back part of the jacket. ISFDB has this record for DAW Books / SFBC which says "Catalog ID: 08-6848" and "Catalog #/price from the SFBC flyer."

My question is - do SFBC fliers, at least in 2009, have the number that's printed on the jacket? I'm wondering if I should edit the existing record, change the catalog #, and update the notes that that the catalog # in the SFBC flier is 08-6848 and that the publication states 1275245. Or should I create a new DAW Books / SFBC publication record for Catalog # 1275245. --Marc Kupper 02:54, 15 November 2018 (EST)

We have some data here. Just adding some notes - I did some digging when we started the "move the ID project for SFBC". My understanding is that 08-6848 should go back down in the notes (even if it is not your book) as it is catalog number and not an ID number (which is what we put in the catalog field). Cannot help much more I am afraid but I am sure someone will be along with more data... Annie 03:03, 15 November 2018 (EST)
I believe the printed 1275245 corresponds to the SFBC catalog number 12-75245, which I then think means it's a different edition from that of the existing record. --MartyD 07:01, 15 November 2018 (EST)
I do not think that the conversion is that clear cut - ID 1353404 has catalog ID 13-534046 for example and not the expected 13-53404 - the catalog always adds one more number at the end... But I would agree that this looks like a different book though... Annie 14:59, 15 November 2018 (EST)
Thank you. I'll go with a new record as the numbers are very different. --Marc Kupper 02:16, 16 November 2018 (EST)

The Witch of Blackbird Pond

Is this book really eligible for being here? As far as I can tell, it's not actually fantasy at all. Rather, it's historical fiction that has multiple people being accused of being a witch in early New England. We have quite a few publications of it listed. Thoughts? ···日本穣 · 投稿 · Talk to Nihonjoe 14:47, 15 November 2018 (EST)

All 3 verifiers are active so why don't we check if one (or more) of them read the book and can tell us if there is anything speculative? Annie 14:56, 15 November 2018 (EST)
Invited. I read it years ago, and I don't remember any speculative fiction content (as defined here) at all. It's just historical fiction. No fantasy, science fiction, or horror at all. ···日本穣 · 投稿 · Talk to Nihonjoe 15:06, 15 November 2018 (EST)
Ah, did not realize you read it. Let's see if someone else has an opinion (as it is a children book, I wonder if we are not looking at fairy tales kinda situation?). If it is indeed not speculative, I agree that it needs zapping. Annie 15:20, 15 November 2018 (EST)
You can read the summary over here, too. ···日本穣 · 投稿 · Talk to Nihonjoe 16:09, 15 November 2018 (EST)
Yeah, I did not see anything there but then half the magical realism sounds non-speculative to me as well (even after I read it) :) Annie 16:24, 15 November 2018 (EST)
I verified it because I had it, and because it was extensively listed on this site. I've been meaning to read it since I was knee-high to a grasshopper, but I still haven't gotten around to it. I'm assuming that it was added back in the early days of this site, and then people just continued to build on this submission. It was a popular book in its day, but to get the real deal on the content of this book you'll probably have to ask some other geriatric case besides me, who has actually read the book. If it has to go the way of the dodo, then so be it. Too bad you can't ask the general contributors of this site. Maybe on the "help" page. MLB 17:02, 15 November 2018 (EST)
Yeah, I have read it (a long time ago) and don't remember anything speculative. --Vasha (cazadora de tildes) 18:32, 15 November 2018 (EST)
Vasha's right, the "witch" angle is the xenophobia and superstition of the New Englanders and their persecution of the title character. Ofearna 23:14, 16 November 2018 (EST)

(unindent) So anyone opposing the deletion of the title (and all the publications containing it)? Annie 23:40, 16 November 2018 (EST)

I have no objection. It might be nice to copy-and-paste the verified pubs' data to their respective verifiers' Talk pages for reference purposes. Ahasuerus 10:22, 17 November 2018 (EST)
Delete away. That book was in a collection I bought, not a keeper or a read-me. Only entered because it was already listed. --~ Bill, Bluesman 13:50, 18 November 2018 (EST)
Deletion has been completed. Those who had verified any of them have the publication information on their talk pages. ···日本穣 · 投稿 · Talk to Nihonjoe 13:58, 19 November 2018 (EST)

Title checkboxes now appear on the same line

As per this discussion, title checkboxes now appear on the same line. The change affects all New Publication edit forms as well as Edit Title. Let's see if the new layout is an improvement.

P.S. You may need to do a full page reload (Control-F5 in most browsers) for everything to display correctly. Ahasuerus 18:56, 15 November 2018 (EST)

They should be a little farther apart: the labels need to be more visually separated from one another. --Vasha (cazadora de tildes) 19:24, 15 November 2018 (EST)
Good point; I have made the changes. Could you please do a full page reload to see if the spacing looks better? Ahasuerus 20:32, 15 November 2018 (EST)
Yes, that's an improvement. --Vasha (cazadora de tildes) 20:37, 15 November 2018 (EST)
Can we do something about the focus on these fields? At the moment it jumps from Content to Synopsis when you tab through it, skipping the checkboxes (both on addPub and editPub). When I am not working on a touchscreen, not needing to use the mouse to navigate the page is pretty useful. These are also the only ones that are skipped :) Annie 20:41, 15 November 2018 (EST)
Sure, let me take a look. Ahasuerus 20:58, 15 November 2018 (EST)
Done. Ahasuerus 21:11, 15 November 2018 (EST)
You are getting faster and faster in fixing these. Thanks! Annie 21:20, 15 November 2018 (EST)

Google search proposal

(copied from above) Re: lower case versions of non-Latin values, I think it will only get us so far whether we enter them in the existing Transliterated Values fields or in the requested new field. Adding "павел вежинов" to "Павел Вежинов" won't help users who type "ПАВЕЛ ВЕЖИНОВ". Without full Unicode support, it will remain a band-aid. Ahasuerus 17:05, 13 November 2018 (EST)

(moved from above) : No, it won't help the guys that write in caps only but combined with a note on the search result page that mentions that if you are using non-standard Latin characters, you should search in small letters, it will be a better band-aid than anything else we can come up with for the short term... I've never called it a solution - just a short term way to make the DB somewhat usable. Annie 17:43, 13 November 2018 (EST)
Well, if the proposed addition of all-lower case versions of titles/names/etc requires an Advanced Search note to be fully functional, wouldn't it be easier to display an Advanced Search note about the need to use the exact case for non-Latin-1 characters? Ahasuerus 19:25, 14 November 2018 (EST)
Yes but that will require you to know the capitalization rules of the language. Which will be ok for speakers of the language; not as good for a researcher that can read the script but has a shaky idea of the language... And then you have Легуин/ Ле Гуин. When we have all the titles, finding either will work but if you had never seen her name written the other way, that "Guin" will trip you. I am not saying that is a perfect solution - away from that. Just trying to find a workaround... If everyone thinks that this will be an overkill, then I am fine with just adding a note to ask "according to language rules" with a link to the new pages we are building. Either will be better than now :)Annie 19:34, 14 November 2018 (EST)
I had been thinking on that. While this will make our search a bit more manageable, it is really a bandaid. And considering the Russian titles, it will take a long time to update all of them. And a user that is not used to the DB won't really do a second search this way... So... why not use google to help us (someone already mentioned it above - I am just slowly warming up to it). Unlike us, it speaks languages and actually can do some level of autocorrect (which is helpful if you are not strong in a language). So... why not modify the search result page and just give the ability to search in google (with the site name added already and so on. So the built-in search is still there for direct matches but we have a viable way for someone to find something if they do not spell exactly as expected. Annie 22:02, 15 November 2018 (EST)
Yes, it was originally proposed by JLaTondre. I can think of a few ways to leverage Google Search:
  1. Add "Google Search" as a new section within Advanced Search [original proposal]
  2. Add a "Google Search" checkbox to the standard search box, which will alter the behavior of the search logic, redirecting it to Google [my original response to the proposal]
  3. If a search (regular or Advanced) fails, display the standard "No matching records found" message, then display a Google Search button with an explanatory note. If clicked, the button will execute a Google Search for the entered value and the appropriate search type.
  4. In addition to option 3 immediately above, even if a search succeeds, display the Google Search button in addition to displaying the standard results table.
My current thinking is that options 3 and arguably 4 may be our best bet. They wouldn't affect the current workflow and would provide additional functionality without interrupting anything.
The only partial failure scenario (that I can think of) would be the regular ISFDB search engine finding only one matching record and automatically redirecting the user to that record's page. That's what we typically want to happen except when we have other "imprecise" matches which our search logic doesn't find. Still, it appears to be a good compromise. Ahasuerus 23:18, 15 November 2018 (EST)
This is an excellent thought. I like your proposal 3. --Vasha (cazadora de tildes) 01:01, 16 November 2018 (EST)
I'd like to see the link as well when there are results - the more titles and authors we get, the more often we will be getting false positives (aka something matching but not you are not looking for...). Add also a checkbox in Advanced Search that allows the search to be done via Google instead of our search (so you do not need to fail a search first) and we should be all set. Annie 01:08, 16 November 2018 (EST)
(After sleeping on it) Modifying Advanced Search to work with Google may be tricky. We support a lot of different permutations ("Reviewed Author is not exactly Павел Вежинов") which may not directly translate to Google queries. We'll have to review Google's documentation to see which parts can be approximated. It may be best to start with our regular Search, which should be much easier to implement. Ahasuerus 09:06, 16 November 2018 (EST)
I think that my statement went away from me :) I was thinking more in the line of "where to put it so I do not need to fail a search first", the Advanced Search sounded as a nice place and I ran with it. I would agree that putting the whole advanced search out is not as easy. Annie 13:46, 16 November 2018 (EST)
Google is a page search engine, not a database field search engine. They are inherently different workflows. I would not do #3 & #4 with advanced search results. There is not a way to duplicate the field logic and the results could be confusing to users. I'm not even sure I would do it with regular search. I was envisioning adding a new section to the Advanced Search page, labeling it Google Search, providing a single pull down to pick the page type (All, Title, Author, etc.) and a single search box for people to enter terms. Could add some explanations regarding quotes for phrases and negatives for not. Why make it complicated? Most people are familiar with search engines already. Yes, it's more focused at the experienced ISFDB user who understands the limitations of the ISFDB search and why you'd want to use it. But I'm not sure #3 & #4 on the basic search help users who aren't. -- JLaTondre (talk) 10:12, 17 November 2018 (EST)
I think the main reason to add a "Google Search" button when the regular search logic finds no matches is to give less experienced users -- who may not realize that our software doesn't support approximate searches, what Advanced Search options are available, etc -- a simple way to recover. Currently, if they enter "павел вежинов" instead of "Павел Вежинов", the software tells them that we don't know anything about "павел вежинов" and that's it. The proposed "Google Search" button would give them the ability to retry the search near instantaneously. Of course, we'd need to add an explanatory note.
That said, I can see the value in creating a separate "Google Search" section within Advanced Search. I expect that only more experienced users will know about it, but hey, experienced users are people too!
It should be fairly easy to implement and tweak as needed, so I have created FR 1226. I am out of sorts at the moment, so it may be some time before I get to it. Ahasuerus 20:43, 17 November 2018 (EST)

New Template: Narrator

A new template, "Narrator", has been created. Help has been updated. Ahasuerus 10:44, 16 November 2018 (EST)

Haldeman's 'All My Sins Remembered' series

I propose changing the name of Joe Haldeman's series that we currently have under the name of 'All My Sins Remembered' to 'Confederación'. There are other 'Confederación' stories that do not appear in the 'All My Sins...' collection, such as the first four stories in Vietnam and Other Alien Worlds. They're usually/generally referred to as Confederación stories, also by Haldeman himself. Feedback appreciated! PeteYoung 02:40, 18 November 2018 (EST)

Yes, I'm all for it. It's plain better as to name it after one of its titles. Stonecreek 09:52, 20 November 2018 (EST)

Midsummer Century by James Blish

With just around 100 pages of text as a stand-alone publication and 95 pp. within the same-named collection this has to be correctly defined as a NOVELLA. If there's no objection, I'll merge it with the existing SHORTFICTION. Stonecreek 09:51, 20 November 2018 (EST)

The title record you linked to says:
Expansion of the version published in Magazine of Fantasy and Science Fiction in April 1972.
Have you done a word count to see if it's under 40,000 words? There are three hardcover editions.1 2 3. The word count, not the page count, is how the stories get classified.
The main support for novella is that it's also part of a collection, Midsummer Century, meaning at present we have a collection that contains a novel plus two other novelettes. --Marc Kupper 23:14, 20 November 2018 (EST)
I've done a word count for the German translation: it comes round 34,000 words. It would be good if it's remembered by whom the note was added, if it's based on an actual word count, or was put there because the publisher called the book publication a novel (anyway, even an expansion doesn't have to mean that it was expanded to more than 40,000 words). And the very most examples of publications in book form have shown that there have to be at least 120 pages of text to qualify it as a novel (sometimes even 140 pages are still a novella). Stonecreek 23:47, 20 November 2018 (EST)
Personal tools