workaround for sorting compound last names

[Noah]

I would like to get other librarian's opinions on a work-around solution the problem of compound last names (such as Miguel de Cervantes Saavedra, Ursula K. Le Guin, etc.) not sorting correctly. I see discussions of this same topic dating back to 2008—with no promises of a fix—so it seems pointless to hope and wait for a "sort by author" field or first/last name fields to be implemented in code.

I had this same problem with another—albeit much smaller—book database, and I solved it by using non-breaking spaces (Unicode character U00A0) between the words of the last name. I did some testing on GR, and it seems to work flawlessly.

A non-breaking space appears exactly the same a regular space, but will join all parts of a last name (like 'Le' and 'Guin') together as if they were one word. This means that the names will show up correctly when sorted (as "Le Guin, Ursula K."). This in no ways affects the ability to search for an author using a regular space in his/her last name.

The only downside I see, is that when new works are imported or added, they will have the author's name spelled with a regular space, so they will not appear properly under the existing author's page. It will not be an easy thing for someone to figure out why this is happening (again, they will look identical), so I feel this would require some active participation by librarians—especially the ones regularly on this discussion board—and/or a change to the librarian manual.

For reference, the last space in this name is a non-breaking space: "Miguel de Cervantes Saavedra."

This could, in theory, be used to tie suffixes to a last name as well, such as "Walter M. Miller Jr."

[Moloch]

This problem has always bugged me a lot: your solution is clever, but the downside part is still potentially too "dangerous" to me: a lot of duplicate authors not easy to spot and to fix. I'd rather wait for the "sort by" for authors, but I got quite discouraged when you said someone has been asking for it since 2008... (I can't help but think it shouldn't be that hard to make, but still I must be wrong)

[Paula]

Before anything like this would be implemented it should be brought up in the feedback group or send the suggest to support at GR to ensure there are no concerns from the technical team

But I agree with Moloch in terms of waiting for a proper solution

[scherzo♫]

I'd prefer a proper solution, but am willing to do some of the work if there's agreement to use non-breaking spaces in the meantime.

[Vicky]

I agree that this issue is irritating, and I agree that your workaround is clever. But I think it would cause more harm than good.

1 - Not everyone will follow this rule, people will not understand what it is and will more than likely overwrite a name with a non-breaking space when they can't figure out what is going on.

2 - Implementing anything that makes it so that librarians have to move imported books to another author profile seems unnecessary. We already do it for disambiguated authors, but there isn't anything we can do about that. Purposely putting ourselves in this position seems like it would be more irritating than the lack of author sort.

3 - When/if an author sort is implemented, the non-breaking space make conflict with the coding for such a thing.

4 - When/if an author sort is implemented, we will probably want to revert all these changes so that we aren't looking after these profiles for new imports for the rest of our Goodreads existence.

5 - There will be people who do not know what is a last name and what is not, someone will make Edgar Allan Poe into Allan Poe, Edgar or someone will make Henry Wadsworth Longfellow sorted under Wadsworth. Yes, I know we can say that Worldcat or the LOC will be the source for this information, but I also know that someone will screw it up and someone will have to fix it.

[James]

The non-breaking space would be a good temporary fix -- if only one could trust that everyone/everything that modifies the GR database was consistent in its use .

I think the name-sorting issue is one that should have long ago been fixed by the programmers. Honestly, it shouldn't be a difficult fix; additionally, segmented last names, suffixes like "Jr.", AND author disambiguation can all be corrected at the same time.

[rivka, Former Moderator]

Vicky wrote: "I agree that this issue is irritating, and I agree that your workaround is clever. But I think it would cause more harm than good."

Agreed.

[Peter]

Noah wrote: "I had this same problem with another—albeit much smaller—book database, and I solved it by using non-breaking spaces (Unicode character U00A0) between the words of the last name. I did some testing on GR, and it seems to work flawlessly. "

For those with the tech savvy to enter such a character, it could be a clever work-around. The tech team may even try using it under the hood.

One problem we may have is that not all librarians would even know what a non-break space is or how to enter one.